base administrator’s guidepublib.boulder.ibm.com/tividd/td/itamos/sc32-1132...this guide is for...

IBM Tivoli Access Manager

Base Administrator’s GuideVersion 4.1

SC32-1132-00

��

NoteBefore using this information and the product it supports, read the information in Appendix C, “Notices” on page 153.

Second Edition (October 2002)

This edition replaces GC23-4684-00.

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

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixWho should read this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixWhat this book contains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixPublications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xRelated publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiAccessing publications online . . . . . . . . . . . . . . . . . . . . . . . . . . . . xivOrdering publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xivProviding feedback about publications . . . . . . . . . . . . . . . . . . . . . . . . . xv

Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvContacting customer support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvConventions used in this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Typeface conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Chapter 1. Tivoli Access Manager overview . . . . . . . . . . . . . . . . . . . . 1Securing the enterprise network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Network security — common concerns . . . . . . . . . . . . . . . . . . . . . . . . . 2Introducing Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Core technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Quality of (data) protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Centralized management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Authorization: conceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5The benefits of a standard authorization service . . . . . . . . . . . . . . . . . . . . . . 6Tivoli Access Manager authorization service overview . . . . . . . . . . . . . . . . . . . . 7

The Tivoli Access Manager authorization service . . . . . . . . . . . . . . . . . . . . . . . 8Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Authorization service interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Replication for scalability and performance . . . . . . . . . . . . . . . . . . . . . . . . 10

Implementing a network security policy . . . . . . . . . . . . . . . . . . . . . . . . . . 11Defining the network security policy . . . . . . . . . . . . . . . . . . . . . . . . . . 11The protected object space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Defining and applying ACL and POP policies . . . . . . . . . . . . . . . . . . . . . . . 12Policy administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14The authorization process: step-by-step . . . . . . . . . . . . . . . . . . . . . . . . . 15

The Tivoli Access Manager authorization API . . . . . . . . . . . . . . . . . . . . . . . . 16Using the authorization API: two examples . . . . . . . . . . . . . . . . . . . . . . . . 17Authorization API: remote cache mode . . . . . . . . . . . . . . . . . . . . . . . . . 18Authorization API: local cache mode . . . . . . . . . . . . . . . . . . . . . . . . . . 19

External authorization capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Extending the authorization service . . . . . . . . . . . . . . . . . . . . . . . . . . 20Imposing conditions on resource requests . . . . . . . . . . . . . . . . . . . . . . . . 21The authorization evaluation process . . . . . . . . . . . . . . . . . . . . . . . . . . 21Implementing an external authorization service . . . . . . . . . . . . . . . . . . . . . . 23Deployment strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Tivoli Access Manager base certificate and password management . . . . . . . . . . . . . . . . . 24Initial configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Keyring database file and stash file renewal information . . . . . . . . . . . . . . . . . . . 25Determining trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Certificate revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Additional considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Default administration users and groups . . . . . . . . . . . . . . . . . . . . . . . . . 28

© Copyright IBM Corp. 1999, 2002 iii

group iv-admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28group ivmgrd-servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Creating administration users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Example administration ACL templates . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 2. Managing the protected object space. . . . . . . . . . . . . . . . . . 31The protected object space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Elements of the protected object space . . . . . . . . . . . . . . . . . . . . . . . . . 31Protected object space hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 32User-defined object space for third-party applications . . . . . . . . . . . . . . . . . . . . 33

Defining a database object space . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Creating a new user-defined container object . . . . . . . . . . . . . . . . . . . . . . . 34Creating and deleting objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 3. Using access control policies . . . . . . . . . . . . . . . . . . . . . 37The ACL policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

ACL policy entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Creating and naming ACL policies . . . . . . . . . . . . . . . . . . . . . . . . . . 38

ACL entry syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Type attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39ID attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Permissions (actions) attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Default Tivoli Access Manager permissions (actions). . . . . . . . . . . . . . . . . . . . . 41

How the authorizations service uses ACL policies . . . . . . . . . . . . . . . . . . . . . . 41Performing operations on an object . . . . . . . . . . . . . . . . . . . . . . . . . . 42Requirements for custom permissions . . . . . . . . . . . . . . . . . . . . . . . . . 42Custom action example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Evaluating an ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Evaluating authenticated requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Evaluating unauthenticated requests . . . . . . . . . . . . . . . . . . . . . . . . . . 43Example ACL entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Sparse ACL model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44ACL inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44The default root ACL policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Traverse permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Resolving an access request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Applying ACL policies to different object types . . . . . . . . . . . . . . . . . . . . . . 47ACL policy inheritance example . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Guidelines for a secure object space . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Creating extended ACL actions and action groups . . . . . . . . . . . . . . . . . . . . . . 48Creating a new action group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Creating new actions in an action group. . . . . . . . . . . . . . . . . . . . . . . . . 50Entering custom actions into ACL entries . . . . . . . . . . . . . . . . . . . . . . . . 50

ACL policies and the protected object space . . . . . . . . . . . . . . . . . . . . . . . . 51Root ( / ) container object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51The traverse permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Management permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52/Management/ACL permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . 52/Management/Action permissions . . . . . . . . . . . . . . . . . . . . . . . . . . 53/Management/POP permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . 54/Management/Server permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . 55/Management/Config permissions . . . . . . . . . . . . . . . . . . . . . . . . . . 55/Management/Policy permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . 55/Management/Replica permissions . . . . . . . . . . . . . . . . . . . . . . . . . . 56/Management/Users permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . 56/Management/Groups permissions . . . . . . . . . . . . . . . . . . . . . . . . . . 57/Management/GSO permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Object and object space permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Default administration ACL policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Default root ACL policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

iv IBM Tivoli Access Manager: Base Administrator’s Guide

Default /Management ACL policy. . . . . . . . . . . . . . . . . . . . . . . . . . . 59Default /Replica ACL policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Default /Config ACL policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Default /GSO ACL policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Default /Policy ACL policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Chapter 4. Protected object policies . . . . . . . . . . . . . . . . . . . . . . . 61Protected object policies (POP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

POP notes:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Creating and deleting protected object policies . . . . . . . . . . . . . . . . . . . . . . 62Applying POP attributes to protected objects . . . . . . . . . . . . . . . . . . . . . . . 63

Configuring the POP attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Warning mode attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Audit level attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Time-of-day attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Authentication strength POP policy (step-up) . . . . . . . . . . . . . . . . . . . . . . . . 65Configuring levels for step-up authentication . . . . . . . . . . . . . . . . . . . . . . . 65Applying step-up authentication policy . . . . . . . . . . . . . . . . . . . . . . . . . 66Distinguishing step-up from multi-factor authentication . . . . . . . . . . . . . . . . . . . 67

Network-based authentication POP policy . . . . . . . . . . . . . . . . . . . . . . . . . 67Specifying IP addresses and ranges . . . . . . . . . . . . . . . . . . . . . . . . . . 68Disabling step-up authentication by IP address . . . . . . . . . . . . . . . . . . . . . . 69Network-based authentication algorithm . . . . . . . . . . . . . . . . . . . . . . . . 69Network-based authentication notes and limitations . . . . . . . . . . . . . . . . . . . . . 69

Quality of protection POP policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Chapter 5. Using Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . 71Delegating administration using Web Portal Manager . . . . . . . . . . . . . . . . . . . . . 71

Accessing the delegate administration functions . . . . . . . . . . . . . . . . . . . . . . 73Delegating role administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Personalizing the interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Functionality of Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Self-registration sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Self-care using Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Chapter 6. Delegating administration tasks . . . . . . . . . . . . . . . . . . . . 79Delegating object space management . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Structuring the object space for management delegation . . . . . . . . . . . . . . . . . . . 79Default administration users and groups . . . . . . . . . . . . . . . . . . . . . . . . 80Example: Management delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Delegating group management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Creating group container objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Creating groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83ACL policies affecting group management . . . . . . . . . . . . . . . . . . . . . . . . 84ACL policies affecting user management . . . . . . . . . . . . . . . . . . . . . . . . 85

Managing delegated administration policy . . . . . . . . . . . . . . . . . . . . . . . . . 86

Chapter 7. Managing Tivoli Access Manager servers . . . . . . . . . . . . . . . . 89Tivoli Access Manager servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Server dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Server configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Tivoli Access Manager utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Starting and stopping Tivoli Access Manager servers . . . . . . . . . . . . . . . . . . . . . 92

Starting and stopping servers on UNIX systems . . . . . . . . . . . . . . . . . . . . . . 92Starting and stopping servers on Windows systems . . . . . . . . . . . . . . . . . . . . . 93

Automating server startup at boot time . . . . . . . . . . . . . . . . . . . . . . . . . . 94Policy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Authorization server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Policy server administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Replicating the authorization database . . . . . . . . . . . . . . . . . . . . . . . . . 94

Contents v

Setting the number of update notifier threads . . . . . . . . . . . . . . . . . . . . . . . 96Setting the notification delay time . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Chapter 8. Managing registries . . . . . . . . . . . . . . . . . . . . . . . . . 97LDAP-specific tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

LDAP fail-over configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Using valid characters for LDAP user and group names . . . . . . . . . . . . . . . . . . . 100Applying Tivoli Access Manager ACLs to new LDAP suffixes . . . . . . . . . . . . . . . . . 101

Active Directory-specific tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Setting up Microsoft Windows 2000 Domain Name System (DNS) for Active Directory . . . . . . . . . 106Updating the Tivoli Access Manager schema . . . . . . . . . . . . . . . . . . . . . . . 107Adding a Tivoli Access Manager user to the Active Directory system group . . . . . . . . . . . . 108

Novell-specific tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Updating Tivoli Access Manager schema . . . . . . . . . . . . . . . . . . . . . . . . 108

Chapter 9. Logging and auditing server activity. . . . . . . . . . . . . . . . . . 111Introduction to logging and auditing . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Audit trail files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Documentation convention: install_path . . . . . . . . . . . . . . . . . . . . . . . . 111

Logging Base serviceability messages . . . . . . . . . . . . . . . . . . . . . . . . . . 112Tivoli Access Manager audit trail files . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Enabling and disabling auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Specifying the log file location . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Specifying audit file rollover thresholds . . . . . . . . . . . . . . . . . . . . . . . . 114Specifying the frequency for flushing audit file buffers . . . . . . . . . . . . . . . . . . . 115Specifying audit events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Audit trail file format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Status attribute of the outcome field . . . . . . . . . . . . . . . . . . . . . . . . . . 117Resource attribute of the target field . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Audit trail file contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Authorization audit records . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Authentication audit records . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Management audit records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Chapter 10. Using event logging . . . . . . . . . . . . . . . . . . . . . . . . 125Tivoli Access Manager events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Configuring event logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Configuring the central event propagation queue . . . . . . . . . . . . . . . . . . . . . 129Specifying the maximum number of events to queue in memory . . . . . . . . . . . . . . . . 129Specifying the event queue high water mark . . . . . . . . . . . . . . . . . . . . . . . 129Specifying the frequency for flushing log file buffers . . . . . . . . . . . . . . . . . . . . 129

Console logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130File logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Specifying the log file location. . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Specifying the log file ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Specifying the maximum log file size . . . . . . . . . . . . . . . . . . . . . . . . . 131Specifying the maximum buffer size . . . . . . . . . . . . . . . . . . . . . . . . . . 132Specifying the maximum number of events to queue in memory . . . . . . . . . . . . . . . . 132Specifying the event queue high water mark . . . . . . . . . . . . . . . . . . . . . . . 132Specifying the frequency for flushing log file buffers . . . . . . . . . . . . . . . . . . . . 133Specifying the file mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Pipe logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Specifying the program to run. . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Specifying the event queuing profile. . . . . . . . . . . . . . . . . . . . . . . . . . 134

Remote logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Specifying the maximum buffer size . . . . . . . . . . . . . . . . . . . . . . . . . . 135Specifying the frequency for flushing the consolidation buffer . . . . . . . . . . . . . . . . . 135Specifying the queue sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Specifying compression of messages . . . . . . . . . . . . . . . . . . . . . . . . . . 135Specifying the error retry timeout . . . . . . . . . . . . . . . . . . . . . . . . . . 135

vi IBM Tivoli Access Manager: Base Administrator’s Guide

Specifying the cache file location . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Specifying the rebind retry timeout . . . . . . . . . . . . . . . . . . . . . . . . . . 136Specifying the remote server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Specifying the remote server port. . . . . . . . . . . . . . . . . . . . . . . . . . . 136Specifying the remote server distinguished name . . . . . . . . . . . . . . . . . . . . . 136

Locating event categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Monitoring log queue performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Appendix A. Server configuration reference . . . . . . . . . . . . . . . . . . . 139activedir.conf reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139domino.conf reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139ivacld.conf reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140ivmgrd.conf reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143ldap.conf reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145pd.conf reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Appendix B. User registry differences . . . . . . . . . . . . . . . . . . . . . . 149

Appendix C. Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Contents vii

viii IBM Tivoli Access Manager: Base Administrator’s Guide

Preface

IBM® Tivoli® Access Manager (Tivoli Access Manager) is the base software that isrequired to run applications in the IBM Tivoli Access Manager product suite. Itenables the integration of IBM Tivoli Access Manager applications that provide awide range of authorization and management solutions. Sold as an integratedsolution, these products provide an access control management solution thatcentralizes network and application security policy for e-business applications.

Note: IBM Tivoli Access Manager is the new name of the previously releasedsoftware entitled Tivoli SecureWay® Policy Director. Also, for users familiarwith the Tivoli SecureWay Policy Director software and documentation, themanagement server is now referred to as the policy server.

The IBM Tivoli Access Manager Base Administrator’s Guide provides a comprehensiveset of procedures and reference information for managing Tivoli Access Managerservers and resources. This guide also provides you with valuable background andconcept information for the wide range of Tivoli Access Manager functionality.

Who should read this bookThis guide is for system administrators responsible for the deployment andadministration of base Tivoli Access Manager software.

Readers should be familiar with the following:v PC and UNIX® operating systemsv Database architecture and conceptsv Security managementv Internet protocols, including HTTP, TCP/IP, File Transfer Protocol (FTP), and

Telnetv Lightweight Directory Access Protocol (LDAP) and directory servicesv Authentication and authorization

What this book containsThis guide contains the following sections:v Chapter 1, “Tivoli Access Manager overview” on page 1

Introduces you to important Tivoli Access Manager concepts and functionalitysuch as: Tivoli Access Manager core technologies and components, theauthorization service model, and implementing a security policy.

v Chapter 2, “Managing the protected object space” on page 31Discusses how Tivoli Access Manager uses a virtual representation of resourcesin a protected object space.

v Chapter 3, “Using access control policies” on page 37Provides a complete reference to access control list (ACL) policies.

v Chapter 4, “Protected object policies” on page 61Provides a complete reference to protected object policies (POP).

v Chapter 5, “Using Web Portal Manager” on page 71

© Copyright IBM Corp. 1999, 2002 ix

Provides supplemental information to tasks provided in the online help system,including delegating administration and self-registration. This Web-based userinterface is included separately on the IBM Tivoli Access Manager Web PortalManager CD for AIX, Solaris Operating Environment, and Windows platforms.

v Chapter 6, “Delegating administration tasks” on page 79Explains how Tivoli Access Manager supports delegated management of theobject space and group management.

v Chapter 7, “Managing Tivoli Access Manager servers” on page 89Provides a technical reference to managing and customizing the operation of theTivoli Access Manager servers.

v Chapter 8, “Managing registries” on page 97Provides a subset of user registry tasks that are specific to the installation ofTivoli Access Manager.

v Chapter 9, “Logging and auditing server activity” on page 111Provides a complete reference to the Tivoli Access Manager logging and auditingcapabilities.

v “ivmgrd.conf reference” on page 143v “ivacld.conf reference” on page 140v “ldap.conf reference” on page 145v Appendix A, “Server configuration reference” on page 139

PublicationsThis section lists publications in the IBM Tivoli Access Manager library and anyother related documents. It also describes how to access Tivoli publications online,how to order Tivoli publications, and how to make comments on Tivolipublications.

IBM Tivoli Access ManagerThe Tivoli Access Manager library is organized into the following categories:v “Release information”v “Base information” on page xiv “WebSEAL information” on page xiv “Web security information” on page xiv “Developer references” on page xiv “Technical supplements” on page xii

Publications in the product library are provided in Portable Document Format(PDF) and HTML format on the Tivoli Information Center Web site:

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

Release informationv IBM Tivoli Access Manager Read Me First Card

GI11-4198-00 (am41_readme.pdf)Provides information for installing and getting started using Tivoli AccessManager.

v IBM Tivoli Access Manager Release NotesSC32-1130-00 (am41_relnotes.pdf)

x IBM Tivoli Access Manager: Base Administrator’s Guide


Provides late-breaking information, such as software limitations, workarounds,and documentation updates.

Base informationv IBM Tivoli Access Manager Base Installation Guide

SC32-1131-00 (am41_install.pdf)Explains how to install, configure, and upgrade Tivoli Access Manager software,including the Web Portal Manager interface.

v IBM Tivoli Access Manager Base Administrator’s GuideSC32-1132-00 (am41_admin.pdf)Describes the concepts and procedures for using Tivoli Access Manager services.Provides instructions for performing tasks from the Web Portal Managerinterface and by using the pdadmin command.

WebSEAL informationv IBM Tivoli Access Manager WebSEAL Installation Guide

SC32-1133-00 (amweb41_install.pdf)Provides installation, configuration, and removal instructions for the WebSEALserver and the WebSEAL application development kit.

v IBM Tivoli Access Manager WebSEAL Administrator’s GuideSC32-1134-00 (amweb41_admin.pdf)Provides background material, administrative procedures, and technicalreference information for using WebSEAL to manage the resources of yoursecure Web domain.

Web security informationv IBM Tivoli Access Manager for WebSphere Application Server User’s Guide

SC32-1136-00 (amwas41_user.pdf)Provides installation, removal, and administration instructions for Tivoli AccessManager for IBM WebSphere® Application Server.

v IBM Tivoli Access Manager for WebLogic Server User’s GuideSC32-1137-00 (amwls41_user.pdf)Provides installation, removal, and administration instructions for Tivoli AccessManager for BEA WebLogic Server.

v IBM Tivoli Access Manager Plug-in for Edge Server User’s GuideSC32-1138-00 (amedge41_user.pdf)Describes how to install, configure, and administer the plug-in for IBMWebSphere Edge Server application.

v IBM Tivoli Access Manager Plug-in for Web Servers User’s GuideSC32-1139-00 (amws41_user.pdf)Provides installation instructions, administration procedures, and technicalreference information for securing your Web domain using the plug-in for Webservers.

Developer referencesv IBM Tivoli Access Manager Authorization C API Developer’s Reference

SC32-1140-00 (am41_authC_devref.pdf)Provides reference material that describes how to use the Tivoli Access Managerauthorization C API and the Access Manager service plug-in interface to addTivoli Access Manager security to applications.

v IBM Tivoli Access Manager Authorization Java Classes Developer’s ReferenceSC32-1141-00 (am41_authJ_devref.pdf)

Preface xi

Provides reference information for using the Java™ language implementation ofthe authorization API to enable an application to use Tivoli Access Managersecurity.

v IBM Tivoli Access Manager Administration C API Developer’s ReferenceSC32-1142-00 (am41_adminC_devref.pdf)Provides reference information about using the administration API to enable anapplication to perform Tivoli Access Manager administration tasks. Thisdocument describes the C implementation of the administration API.

v IBM Tivoli Access Manager Administration Java Classes Developer’s ReferenceSC32-1143-00 (am41_adminJ_devref.pdf)Provides reference information for using the Java language implementation ofthe administration API to enable an application to perform Tivoli AccessManager administration tasks.

v IBM Tivoli Access Manager WebSEAL Developer’s ReferenceSC32-1135-00 (amweb41_devref.pdf)Provides administration and programming information for the Cross-domainAuthentication Service (CDAS), the Cross-domain Mapping Framework (CDMF),and the Password Strength Module.

Technical supplementsv IBM Tivoli Access Manager Command Reference

GC32-1107-00 (am41_cmdref.pdf)Provides information about the command line utilities and scripts provided withTivoli Access Manager.

v IBM Tivoli Access Manager Error Message ReferenceSC32-1144-00 (am41_error_ref.pdf)Provides explanations and recommended actions for the messages produced byTivoli Access Manager.

v IBM Tivoli Access Manager Problem Determination GuideGC32-1106-00 (am41_pdg.pdf)Provides problem determination information for Tivoli Access Manager.

v IBM Tivoli Access Manager Performance Tuning GuideSC32-1145-00 (am41_perftune.pdf)Provides performance tuning information for an environment consisting of TivoliAccess Manager with the IBM Directory server defined as the user registry.

The Tivoli Glossary includes definitions for many of the technical terms related toTivoli software. The Tivoli Glossary is available, in English only, at:

http://www.tivoli.com/support/documents/glossary/termsm03.htm

For additional sources of information about Tivoli Access Manager and relatedtopics, see:

http://www.ibm.com/redbookshttp://www.ibm.com/software/sysmgmt/products/support/Field_Guides.html

Related publicationsThis section lists publications related to the Tivoli Access Manager library.

xii IBM Tivoli Access Manager: Base Administrator’s Guide

http://www.tivoli.com/support/documents/glossary/termsm03.htm

http://www.ibm.com/redbooks

http://www.ibm.com/software/sysmgmt/products/support/Field_Guides.html

IBM Global Security ToolkitTivoli Access Manager provides data encryption through the use of the IBM GlobalSecurity Toolkit (GSKit). GSKit is included on the IBM Tivoli Access Manager BaseCD for your particular platform.

The GSKit package installs the iKeyman key management utility, gsk5ikm, whichenables you to create key databases, public-private key pairs, and certificaterequests. The following document is available on the Tivoli Information CenterWeb site in the same section as the IBM Tivoli Access Manager productdocumentation:v Secure Sockets Layer Introduction and iKeyman User’s Guide

(gskikm5c.pdf)Provides information for network or system security administrators who plan toenable SSL communication in their Tivoli Access Manager secure domain.

IBM DB2 Universal DatabaseIBM DB2® Universal Database™ is required when installing IBM Directory Server,z/OS™, and OS/390® LDAP servers. DB2 is provided on the product CDs for thefollowing operating system platforms:v IBM AIX®

v Microsoft™ Windows™

v Sun Solaris Operating Environment

DB2 information is available at:

http://www.ibm.com/software/data/db2/

IBM Directory ServerIBM Directory Server, Version 4.1, is included on the IBM Tivoli Access ManagerBase CD for all platforms except Linux for zSeries™. You can obtain the IBMDirectory Server software for Linux for S/390 at:

http://www.ibm.com/software/network/directory/server/download/

If you plan to use IBM Directory Server as your user registry, see the informationprovided at:

http://www.ibm.com/software/network/directory/library/

IBM WebSphere Application ServerIBM WebSphere Application Server, Advanced Single Server Edition 4.0.3, isincluded on the Web Portal Manager CDs and installed with the Web PortalManager interface. For information about IBM WebSphere Application Server, see:

http://www.ibm.com/software/webservers/appserv/infocenter.html

IBM Tivoli Access Manager for Business IntegrationIBM Tivoli Access Manager for Business Integration, available as a separatelyorderable product, provides a security solution for IBM MQSeries®, Version 5.2,and IBM WebSphere® MQ for Version 5.3 messages. IBM Tivoli Access Manager forBusiness Integration allows WebSphere MQSeries applications to send data withprivacy and integrity by using keys associated with sending and receivingapplications. Like WebSEAL and IBM Tivoli Access Manager for OperatingSystems, IBM Tivoli Access Manager for Business Integration, is one of theresource managers that use the authorization services of IBM Tivoli AccessManager for e-business.

Preface xiii

http://www.ibm.com/software/data/db2/

http://www.ibm.com/software/network/directory/server/download/

http://www.ibm.com/software/network/directory/library/

http://www.ibm.com/software/webservers/appserv/infocenter.html

The following documents associated with IBM Tivoli Access Manager for BusinessIntegration Version 4.1 are available on the Tivoli Information Center Web site:v IBM Tivoli Access Manager for Business Integration Administrator’s Guide

(SC23-4831-00)v IBM Tivoli Access Manager for Business Integration Release Notes (GI11-0957-00)v IBM Tivoli Access Manager for Business Integration Read Me First (GI11-0958-00)

IBM Tivoli Access Manager for Operating SystemsIBM Tivoli Access Manager for Operating Systems, available as a separatelyorderable product, provides a layer of authorization policy enforcement on UNIXsystems in addition to that provided by the native operating system. IBM TivoliAccess Manager for Operating Systems, like WebSEAL and IBM Tivoli AccessManager for Business Integration, is one of the resource managers that use theauthorization services of IBM Tivoli Access Manager for e-business.

The following documents associated with IBM Tivoli Access Manager forOperating Systems Version 4.1 are available on the Tivoli Information Center Website:v IBM Tivoli Access Manager for Operating Systems Installation Guide (SC23-4829-00)v IBM Tivoli Access Manager for Operating Systems Administration Guide

(SC23-4827-00)v IBM Tivoli Access Manager for Operating Systems Problem Determination Guide

(SC23-4828-00)v IBM Tivoli Access Manager for Operating Systems Release Notes (GI11-0951-00)v IBM Tivoli Access Manager for Operating Systems Read Me First (GI11-0949-00)

Accessing publications onlineWhen IBM publishes an updated version of one or more online or hardcopypublications, they are posted to the Tivoli Information Center. The TivoliInformation Center contains the most recent version of the publications in theproduct library in PDF or HTML format, or both. Translated documents are alsoavailable for some products.

You can access updated publications in the Tivoli Information Center and othersources of technical information from the following Customer Support Web site:


Information is organized by product, including release notes, installation guides,user’s guides, administrator’s guides, and developer’s references.

Note: If you print PDF documents on other than letter-sized paper, select the Fit topage check box in the Adobe Acrobat Print dialog (which is available whenyou click File → Print) to ensure that the full dimensions of a letter-sizedpage are printed on the paper that you are using.

Ordering publicationsYou can order many Tivoli publications online at:

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

You can also order by telephone by calling one of these numbers:

xiv IBM Tivoli Access Manager: Base Administrator’s Guide


http://www.elink.ibmlink.ibm.com/public/applications/ publications/cgibin/pbi.cgi

http://www.elink.ibmlink.ibm.com/public/applications/ publications/cgibin/pbi.cgi

v In the United States: 800-879-2755v In Canada: 800-426-4968v In other countries, for a list of telephone numbers, see:

http://www.tivoli.com/inside/store/lit_order.html

Providing feedback about publicationsIf you have comments or suggestions about Tivoli products and documentation,complete the customer feedback survey at:

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

AccessibilityAccessibility features help a user who has a physical disability, such as restrictedmobility or limited vision, to use software products successfully. With this product,you can use assistive technologies to hear and navigate the interface. You also canuse the keyboard instead of the mouse to operate all features of the graphical userinterface.

Contacting customer supportIf you have a problem with any Tivoli product, you can contact IBM CustomerSupport for Tivoli products. See the Tivoli Customer Support Handbook at thefollowing Web site:

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

The handbook provides information about how to contact Customer Support,depending on the severity of your problem, and the following information:v Registration and eligibilityv Telephone numbers and e-mail addresses, depending on the country in which

you are locatedv What information you should gather before contacting Customer Support

Conventions used in this bookThis guide uses several conventions for special terms and actions, operatingsystem-dependent commands and paths, and margin graphics.

Typeface conventionsThe following typeface conventions are used in this book:

Bold Command names and options, keywords, and other informationthat you must use literally appear in bold.

Italic Variables, command options, and values you must provide appearin italics. Titles of publications and special words or phrases thatare emphasized also appear in italics.

Monospace Code examples, command lines, screen output, file and directorynames, and system messages appear in monospace font.

Preface xv

http://www.tivoli.com/inside/store/lit_order.html

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

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

xvi IBM Tivoli Access Manager: Base Administrator’s Guide

Chapter 1. Tivoli Access Manager overview

IBM Tivoli Access Manager is a complete authorization solution for corporate Web,client/server, Tivoli Access Manager applications, and legacy (preexisting)applications. Tivoli Access Manager authorization allows an organization tosecurely control user access to protected information and resources. By providing acentralized, flexible, and scalable access control solution, Tivoli Access Managerallows you to build highly secure and well-managed network-based applicationsand e-business infrastructure.

This chapter contains the following sections:v “Securing the enterprise network” on page 1v “Core technologies” on page 3v “Authorization: conceptual model” on page 5v “The Tivoli Access Manager authorization service” on page 8v “Implementing a network security policy” on page 11v “The Tivoli Access Manager authorization API” on page 16v “External authorization capability” on page 20v “Tivoli Access Manager base certificate and password management” on page 24

Securing the enterprise networkMany organizations now value the public Internet and private intranets as effectiveand vital mediums for global communication. Electronic commerce, or e-business,has rapidly become an essential component of many business marketing strategies.Educational institutions rely on the Internet for long-distance learning. Onlineservices allow individuals to send electronic mail and to tap the Web’s vastencyclopedia of resources. Traditional applications, such as TELNET and POP3,still prevail as important network services.

Businesses are realizing that they can use Internet technologies to enhance supplychain relationships, facilitate collaboration with business partners, and provideincreased customer connectivity—provided they can expose corporate resourceswith a high degree of security. Businesses want to use the Internet as a globalcommercial and distribution vehicle, but have been hindered by the lack of provensecurity policy mechanisms and management systems.

Tivoli Access Manager is an information policy management solution that providesorganizations with centralized network security services—where you canconsistently implement and maintain corporate security policy.

Tivoli Access Manager provides the three primary requirements for a balancedsecurity solution:v A variety of solutions for creating a highly secure network environmentv Convenient and intuitive management tools for secure centralized administrationv Security mechanisms that do not hinder permitted client activity on the network

© Copyright IBM Corp. 1999, 2002 1

Network security — common concernsBoth the worldwide public Internet and company-private intranets connect toheterogeneous computer systems, applications, and networks. This mixture ofdissimilar hardware and software usually impacts a network in the followingways:v No centralized control of security for applicationsv No unified resource location naming conventionv No common support for high availability of applicationsv No common support for scalable growth

New business models require organizations to expose their information resourcesto a previously unthought of degree. These businesses need to know that they cansecurely control access to those resources.

Managing policy and users across distributed networks has proven difficult forInformation Technology (IT) managers, especially because individual applicationand system vendors implement authorization in their own proprietary fashion.

Companies realize that developing new authorization services for each enterpriseapplication is an expensive process that leads to a difficult-to-manageinfrastructure. A centralized authorization service that is accessed by developersthrough a standardized API could greatly speed time to market and reduce totalcost of ownership.

A centralized network security management system needs to fulfill requirementsthat include:v Coexisting with or leveraging (or both) existing firewall and authenticator

architecturesv Integrating or coexisting with network and application management frameworksv Being application-independent

Introducing Tivoli Access ManagerTivoli Access Manager is a complete authorization and network security policymanagement solution that provides unsurpassed end-to-end protection of resourcesover geographically dispersed intranets and extranets.

In addition to its state-of-the-art security policy management feature, Tivoli AccessManager supports authentication, authorization, data security, and resourcemanagement capabilities. You use Tivoli Access Manager in conjunction withstandard Internet-based applications to build highly secure and well-managedintranets.

At its core, Tivoli Access Manager provides:v Authentication framework

Tivoli Access Manager provides a wide range of built-in authenticators andsupports external authenticators.

v Authorization frameworkThe Tivoli Access Manager authorization service, accessed through a standardauthorization API, provides permit and deny decisions on access requests fornative Tivoli Access Manager servers and third-party applications.

2 IBM Tivoli Access Manager: Base Administrator’s Guide

With Tivoli Access Manager, businesses can now securely manage access to privateinternal network-based resources and leverage the public Internet’s broadconnectivity and ease of use. Tivoli Access Manager, in combination with acorporate firewall system, can fully protect the Enterprise intranet fromunauthorized access and intrusion.

The authorization service API standardAuthorization services are a critical part of an application’s security architecture.After a user passes the authentication process, authorization services proceed toenforce the business policy by determining what services and information the usercan access.

For example, a user accessing a Web-based retirement fund would be able to viewpersonal account information after an authorization server verifies the identity,credentials, and privilege attributes of that user.

The standards-based authorization API allows applications to make calls to thecentralized authorization service; thus, eliminating the necessity for developers towrite authorization code for each new application.

The authorization API allows businesses to standardize all applications on atrusted authorization framework. With the authorization API, businesses canprovide more control over access to resources on their networks.

Core technologiesThe Tivoli Access Manager network security management solution provides andsupports the following core technologies:v Authenticationv Authorizationv Quality of protectionv Scalabilityv Accountabilityv Centralized management

AuthenticationAuthentication is the first step a user must take when making a request for aresource from a network protected by Tivoli Access Manager. The authenticationprocess is usually dependent on the specific requirements of the service-providingapplication. Tivoli Access Manager allows a highly flexible approach toauthentication through the use of the authorization API.

Tivoli Access Manager Base provides built-in support of user name and passwordauthentication through the authorization API. Developers can build any customauthentication mechanism that uses the authorization API.

Authorizationv Tivoli Access Manager authorization servicev Access control lists (ACL) and protected object policies (POP) for fine-grained

access controlv Standards-based authorization APIv External authorization service capability

Chapter 1. Tivoli Access Manager overview 3

Quality of (data) protectionQuality of protection is the degree to which Tivoli Access Manager protects anyinformation transmitted between client and server. Quality of protection isdetermined by the combined effect of encryption standards andmodification-detection algorithms.

Quality of protection levels include:v Standard TCP communication (no protection)v Data integrity – protects messages (data stream) from being modified during

network communicationv Data privacy – protects messages from being modified or inspected during

network communication

Supported Encryption StandardsTivoli Access Manager supports the following encryption ciphers over SSL:v 40-bit RC2v 128-bit RC2v 40-bit RC4v 128-bit RC4v 40-bit DESv 56-bit DESv 168-bit triple DES

Secure communicationTivoli Access Manager supports the data integrity and data privacy provided bythe Secure Socket Layer (SSL) communication protocol.

The SSL handshake protocol was developed by Netscape CommunicationsCorporation to provide security and privacy over the Internet. SSL works by usingpublic key for authentication and secret key to encrypt data that is transferred overthe SSL connection.

ScalabilityScalability is the ability to respond to increasing numbers of users who accessresources in the secure domain. Tivoli Access Manager uses the followingtechniques to provide scalability:v Replication of services

– Authentication services– Authorization services– Security policies– Data encryption services– Auditing services

v Front-end replicated servers– Mirrored resources for high availability– Load balancing client requests

v Back-end replicated servers– Back-end servers can be WebSEAL or third-party application servers– Mirrored resources (unified object space) for high availability– Additional content and resources


– Load balancing of incoming requests through junctionsv Optimized performance by allowing the off-loading of authentication and

authorization services to separate serversv Scaled deployment of services without increasing management overhead

AccountabilityTivoli Access Manager provides a number of logging and auditing capabilities.There are log files that capture any error and warning messages generated byTivoli Access Manager servers. There are also audit trail files that monitor TivoliAccess Manager server activity.

Log files:v Tivoli Access Manager server log filesv Serviceability messagesv Standard HTTP log files

Audit trail files:v Tivoli Access Manager server audit trail files

Centralized managementv Web portal managerv pdadmin command line utility

Authorization: conceptual modelWhen servers enforce security in a secure domain, each client must provide proofof its identity. In turn, security policy determines whether that client is permittedto perform an operation on a requested resource. Because access to every resourcein a secure domain is controlled by a server, the server’s demands forauthentication and authorization can provide comprehensive network security.

In security systems, authorization is distinct from authentication. Authorizationdetermines whether an authenticated client has the right to perform an operationon a specific resource in a secure domain. Authentication ensures that theindividual is who he claims to be, but says nothing about the rights to performoperations on a protected resource.

In the Tivoli Access Manager authorization model, authorization policy isimplemented independently of the mechanism used for user authentication. Userscan authenticate their identity using either public/private key, secret key, orcustomer-defined mechanisms.

Part of the authentication process involves the creation of a credential thatdescribes the identity of the client. Authorization decisions made by anauthorization service are based on user credentials.

The resources in a secure domain receive a level of protection as dictated by thesecurity policy for the domain. The security policy defines the legitimateparticipants of the secure domain and the degree of protection surrounding eachresource requiring protection.

The basic components of the authorization process, as shown in Figure 1 on page 6,include:


v A resource manager responsible for implementing the requested operation whenauthorization is granted.A component of the resource manager is a policy enforcer that directs therequest to the authorization service for processing.

v An authorization service that performs the decision-making action on therequest.

Traditional applications bundle the policy enforcer and resource manager into oneprocess. Examples of this structure include Tivoli Access Manager WebSEAL andthird-party applications.

The independent functionality of these authorization components allows muchflexibility in the design of the security enforcement strategy.

For example, such independence allows the security administrator to control:v Where the processes are locatedv Who writes the code for the processesv How the processes perform their tasks

The benefits of a standard authorization serviceAuthorization in most systems, both legacy and new, is tightly coupled toindividual applications. Companies typically build applications over time to servetheir business needs. Many of these applications require some specific form ofauthorization.

The result is often a wide variety of applications with differing authorizationimplementations. These proprietary authorization implementations require separateadministration, are difficult to integrate, and result in higher costs of ownership.

A distributed authorization service can provide these independent applicationswith a standard authorization decision-making mechanism. Benefits of such astandard authorization service would include:v Reduced cost of developing and managing access to applications

ResourceManager

AuthenticatedClient

AuthorizationCheck

Yes / No

Request forResource

AuthorizationService

PolicyEnforcer

Resources

ApplicationServer

Figure 1. General authorization model


v Reduced total cost of ownership and management of separate authorizationsystems

v Leverage of existing security infrastructurev Allow new businesses to open more securelyv Enable newer and different kinds of applicationsv Allow shorter development cyclesv Share information securely

Tivoli Access Manager authorization service overviewTivoli Access Manager integrates into existing legacy and emerging infrastructuresand provides secure, centralized policy management capability. The Tivoli AccessManager authorization service—together with resource managers—provides astandard authorization mechanism for business network systems.

Existing applications can take advantage of the authorization service. Authorizationpolicy is based on user or group roles and can be applied to network servers,individual transactions or database requests, specific Web-based information,management activities, and user-defined objects.

The authorization API allows existing applications to make calls to theauthorization service which in turn makes decisions based on the corporatesecurity policy. For more information on authorization API, see “The Tivoli AccessManager authorization API” on page 16.

The Tivoli Access Manager authorization service is also extensible and can beconfigured to call on other authorization services for additional processing usingthe external authorization service plug-in interface.

The authorization service provides the following benefits:v The service is application independent.v The service uses a standard authorization coding style that is language

independent (the authorization API).v The service is centrally managed and therefore easy to administer — the

addition of a new employee, for example, requires modifying the privilegedatabase in one central location, rather than across multiple systems.

v The service addresses the application of security services in a heterogeneouscross-platform environment.

v The service integrates existing non-Tivoli Access Manager authorization systemsthrough an external authorization service capability.

v The service has a scalable and flexible architecture that can be easily integratedwith existing infrastructure.

v The service enables multi-tiered authorization — a credentials packet can bepassed through the multiple layers of an application process or transaction.

v The service uses a common and effective auditing model.v The service is independent of any authentication mechanism.


The Tivoli Access Manager authorization serviceThe Tivoli Access Manager authorization service is responsible for theauthorization decision-making process that helps to enforce a network securitypolicy. Authorization decisions made by the authorization service result in theapproval or denial of client requests to perform operations on protected resourcesin the secure domain.

ComponentsThe authorization service is made up of three basic components:v Master authorization policy databasev Policy serverv The authorization decision-making evaluator

Master authorization policy databaseThe master authorization policy database contains the security policy informationfor all resources in the secure domain. You can use the Web portal manager orpdadmin utility to enter and modify the contents of this database.

Policy server (pdmgrd)The policy server maintains the master authorization policy database, replicatesthis policy information throughout the secure domain, and updates the databasereplicas whenever a change is made to the master.

The policy server also maintains location information about the other Tivoli AccessManager and non-Tivoli Access Manager servers operating in the secure domain.

Note: There must be only one instance of the policy server in any secure domain.

Authorization evaluatorThe authorization evaluator is the decision-making process that determines aclient’s ability to access a protected resource based on the security policy. Theevaluator makes its recommendation to the resource manager which, in turn,responds accordingly.

Registry database replication parameters are configurable for each evaluator.

Figure 2 on page 9 illustrates the main components of the authorization service:


Authorization service interfacesThe authorization service has two interfaces where interaction takes place:v Management interface — The security administrator manages the security

policy of the network by using the Web portal manager (or the pdadmin utilityor both) to apply policy rules (templates) on resources in the secure domain.The Web portal manager applies this security policy data to the masterauthorization policy database through the policy server.This interface is complex and involves detailed knowledge of the object space,policy templates, and credentials.

v Authorization API — The authorization API passes requests for authorizationdecisions from the resource manager to the authorization evaluator which thenpasses back a recommendation.

Authorization Service

PolicyServer

( )pdmgrdMaster

AuthorizationPolicy

AuthorizationEvaluator

AuthAPI

ResourceManager

Web PortalManager

ReplicaAuthorization

Policy

ManagementInterface

Figure 2. Authorization service components


Replication for scalability and performanceAuthorization service components can be replicated to increase availability in aheavy-demand environment.

You can configure the master authorization policy database, containing policy rulesand credential information, to automatically replicate. Applications that call theauthorization service have two options for referencing this database information:v The application — when configured to work seamlessly with the authorization

evaluator — uses a local cache of the databaseThe database is replicated for each application that uses the authorization servicein local cache mode.

v The application uses a shared replica cached by the remote authorization servercomponentThe database is replicated for each instance of the authorization server. Manyapplications can access a single authorization server.

Update notification from the policy server (whenever a change has been made tothe master authorization policy database) triggers the caching process to update allreplicas.


PolicyServer

( )pdmgrdMaster

AuthorizationPolicy


AuthAPI

ResourceManager

Web PortalManager


Policy

ManagementInterface

Figure 3. Authorization service: interfaces


Performance notesv In addition to update notifications direct from the policy server, the application

servers also check the version of the master authorization policy database everyfew minutes to ensure they have not missed an update notification.If an update notification fails to reach a server, a log entry is created. In bothcases a retry mechanism also ensures the update happens in the future.

v The cached authorization policy information results in high system performance.For example, when WebSEAL does an authorization check, it checks the policytemplate in its own cached version of the database. WebSEAL does not have toaccess the network to obtain this information from the master database. Theresult is very fast response times (performance) for authorization checks.

v Individual authorization results are not cached by the calling application server.

Implementing a network security policyThe security policy for a secure domain is determined by controlling user andgroup participation in the domain and applying rules, known as access control list(ACL) policies and protected object policies (POP), to resources requiringprotection. The authorization service enforces these policies by matching a user’scredentials with the permissions in the policy assigned to the requested resource.The resulting recommendation is passed to the resource manager, which completesthe response to the original request.

Defining the network security policyThe authorization service uses a central database that lists all resources in thesecure domain and the ACL and POP policies assigned to each resource. Thismaster authorization policy database and the user registry (containing user andgroup accounts) are the key components that help define a network security policy.

In summary, a network security policy controls:v Users and groups allowed to participate in the secure domain

The user registry maintains this information.


Policy


Policy


PolicyServer

(pdmgrd)Master

AuthorizationPolicy

Web PortalManager


AuthAPI

ResourceManager


Policy

Figure 4. Replicated authorization service components


v The level of protection on all objects in the secure domainThe master authorization policy database maintains this information.

The protected object spaceThe protected object space is a hierarchical portrayal of resources belonging to asecure domain. The objects that appear in the hierarchical object space representthe actual network resources.v System resource — the actual physical file or application.v Protected object — the logical representation of an actual system resource used

by the authorization service, the Web portal manager, and other Tivoli AccessManager management utilities.

Policy templates can be attached to objects in the object space to provide protectionof the resource. The authorization service makes authorization decisions basedthese templates.

The following object space categories are used by Tivoli Access Manager:v Web objects

These objects represent anything that can be addressed by an HTTP URL. Thisincludes static Web pages and dynamic URLs that are converted to databasequeries or some other type of application.

v Tivoli Access Manager management objects

These objects represent the management activities that can be performed throughthe Web portal manager. The objects represent the tasks necessary to defineusers and set security policy. Tivoli Access Manager supports delegation ofmanagement activities and can restrict an administrator’s ability to set securitypolicy to a subset of the object space.

v User-defined objects

These objects represent customer-defined tasks or network resources protectedby applications using the authorization service through the authorization API.

Defining and applying ACL and POP policiesSecurity administrators protect system resources by defining rules, known as ACLand POP policies, and applying these policies to the object representations of thoseresources in the object space.

ManagementObjects

WebObjects

User-DefinedObjects

Figure 5. Tivoli Access Manager protected object space


The authorization service performs authorization decisions based on the policiesapplied to these objects. When a requested operation on a protected object ispermitted, the application responsible for the resource implements this operation.

One policy can dictate the protection parameters of many objects. Any change tothe rule affects all objects to which the template is attached.

Explicit and inherited policyPolicy can be explicitly applied or inherited. The Tivoli Access Manager protectedobject space supports inheritance of ACL and POP attributes. This is an importantconsideration for the security administrator who manages the object space. Theadministrator needs to apply explicit policies only at points in the hierarchy wherethe rules must change.

Examples of types of policy include:v Hard-coded rulesv External authorization capabilityv Special secure labelingv Access control lists (ACLs)

The access control list (ACL)An access control list policy, or ACL policy, is the set of controls (permissions) thatspecifies the conditions necessary to perform certain operations on that resource.ACL policy definitions are important components of the security policy establishedfor the secure domain. ACL policies, like all policies, are used to stamp anorganization’s security standards onto the resources represented in the protectedobject space.

An ACL policy specifically controls the following:1. What operations can be performed on the resource2. Who can perform these operations

An ACL policy is made up of one or more entries that include user and groupdesignations and their specific permissions or rights.

ManagementObjects

WebObjects

User-DefinedObjects

Explicit RuleInherited

Rule

Figure 6. Explicit and inherited policies


Protected object policies (POP)ACL policies provide the authorization service with information to make a yes orno answer on a request to access a protected object and perform some operation onthat object.

POP policies contain additional conditions on the request that are passed back toTivoli Access Manager Base and the resource manager along with the yes ACLpolicy decision from the authorization service. It is the responsibility of TivoliAccess Manager and the resource manager to enforce the POP conditions.

Available attributes for a POP are listed as follows:

Enforced by Tivoli Access Manager Base

POP attribute Description

Name Name of the policy. This becomes the pop_name in thepdadmin pop commands.

Description Descriptive text for the policy. This appears in the popshow command.

Warning mode Provides administrators a means to test ACL and POPpolicies.

Audit level Specifies type of auditing: all, none, successful access,denied access, errors.

Time-of-day Access Day and time restrictions for successful access to theprotected object.

IP endpoint authorizationmethod policy

Specifies authorization requirements for access frommembers of external networks.

Enforced by resource manager (such as WebSEAL)

POP attribute Description

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

IP endpoint authenticationmethod policy

Specifies authentication requirements for access frommembers of external networks.

Policy administrationThe Web Portal Manager is a Web-based graphical application used to managesecurity policy in a secure domain. The pdadmin command line utility provides

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

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

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

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

ACL(containing multiple

entries)

Figure 7. ACL policy


the same user and group administration capabilities as the Web Portal Manager,plus many commands not supported by the Web Portal Manager.

From the Web Portal Manager (or pdadmin), you can manage the user registry, themaster authorization policy database, and the Tivoli Access Manager servers. Youcan also add and delete users / groups and apply ACL and POP policies toresources.

Note: For delegated administration, you should use one type of interface—eitherthe Web Portal Manager or pdadmin—throughout the entire process foroptimal results.

The authorization process: step-by-stepFigure 9 on page 16 illustrates the complete authorization process:

SecurityServer

Web PortalManager

Windows NT

Workstation

MasterAuthorization

Policy

UserRegistry

PolicyServer

Apply policies on theprotected object space

Create, modify, anddelete user and group

accounts

Figure 8. Web portal manager: Administration of the security policy


1. An authenticated client request for a resource is directed to the resourcemanager server and intercepted by the policy enforcer process. The resourcemanager can be WebSEAL (for HTTP, HTTPS access) or a third-partyapplication.

2. The policy enforcer process uses the authorization API to call the authorizationservice for an authorization decision. For more information on theauthorization API, see “The Tivoli Access Manager authorization API”.

3. The authorization service performs an authorization check on the resource,represented as an object in the protected object space. Base POP policies arechecked first. Next, the ACL policy attached to the object is checked against theclient’s credentials. Then, POP policies enforced by the resource manager arechecked.

4. The decision to accept or deny the request is returned as a recommendation tothe resource manager (through the policy enforcer).

5. If the request is finally approved, the resource manager passes the request on tothe application responsible for the resource.

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

The Tivoli Access Manager authorization APIThe Tivoli Access Manager authorization application programming interface (API)allows Tivoli Access Manager applications and third-party applications to querythe authorization service to make authorization decisions.

The authorization API is the interface between the resource manager (requestingthe authorization check) and the authorization service itself. The authorization APIallows the policy-enforcing application to ask for an authorization decision, butshields the application from the complexities of the actual decision-making process.

The authorization API provides a standard programming model for codingauthorization requests and decisions. The authorization API lets you makestandardized calls to the centrally managed authorization service from any legacyor newly developed application.

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 9. The Tivoli Access Manager authorization process


The authorization API can be used in one of two modes:v Remote cache mode

In this mode, the API is initialized to call the (remote) authorization server(pdacld) to perform authorization decisions on behalf of the application. Theauthorization server maintains its own cache of the replica authorization policydatabase. This mode is best suited for handling authorization requests fromapplication clients.For more information on remote cache mode, see “Authorization API: remotecache mode” on page 18.

v Local cache mode

In this mode, the API is initialized to download and maintain a local replica ofthe authorization database for the application. Local cache mode provides betterperformance because the application performs all authorization decisions locallyinstead of across a network. However, the overhead of database replication andthe security implications of using this mode make it best suited for use bytrusted application servers.For more information on local cache mode, see “Authorization API: local cachemode” on page 19.

One of the primary values and benefits of the authorization API is its ability toshield the user from the complexities of the authorization service mechanism itself.Issues of management, storage, caching, replication, credential formats, andauthentication methods are all hidden behind the authorization API.

The authorization API also works independently from the underlying securityinfrastructure, the credential format, and the evaluating mechanism. Theauthorization API makes it possible to request an authorization check and get asimple yes or no recommendation in return. The details of the authorization checkmechanism are invisible to the user.

Using the authorization API: two examplesThird-party applications can use the authorization API to perform access control onvery specific and specialized processes.

Example 1:

A graphical user interface can be designed to dynamically show task buttons asactive or inactive, according to the results of the authorization check.

Example 2:

Another use of the authorization API is demonstrated in Figure 10 on page 18,illustrating a request for a CGI transaction by a Web application.

The lowest level of authorization, as illustrated in Figure A of Figure 10 on page 18,involves an “all-or-nothing” access control on the URL. This coarse-grained level ofauthorization only determines if the client can run the CGI program. If access isallowed to the CGI application, no further control is available to resourcesmanipulated by the CGI application.

As illustrated in Figure B of Figure 10 on page 18, access controls have been set onresources that the CGI program manipulates. The Web application is configured touse the authorization API. Now the CGI program can call the authorization service


to make authorization decisions on the resources it manipulates — based on theidentity of the requesting client.

Authorization API: remote cache modeIn remote cache mode, applications use the function calls provided by theauthorization API to communicate to the (remote) authorization server (pdacld).The authorization server functions as the authorization decision-making evaluatorand maintains its own replica authorization policy database.

The authorization server makes the decision and returns a recommendation to theapplication through the API. The server can also write an audit record containingthe details of the authorization decision request.

There must be an authorization server running somewhere in the secure domain.The authorization server can be located on the same machine as the application oron another machine. You can also install the authorization server on more than onemachine in a secure domain to allow for high availability. The authorization APItransparently performs fail-over when a particular authorization server fails.

Third-PartyApplication

Client

WebApplication

ObjectsManipulated

by CGI



Client

WebApplication

ObjectsManipulated

by CGI


Figure A

Figure B

Fine-grainedAuthorized

AccessRequest

Response

Request

Response

Coarse-grainedAccess

API

Function Call

Figure 10. Example use of the authorization API


Authorization API: local cache modeIn local cache mode, the API downloads and maintains a replica of theauthorization policy database on the application’s local file system. It performs allauthorization decisions in-memory, which results in higher performance and betterreliability.

The local replica is persistent across invocations of the application. When the APIstarts in replica mode, it checks for any updates to the master authorization policydatabase that might have occurred since the local replica was built.

AuthAPI


PolicyServer

(pdmgrd)Master

AuthorizationPolicy


AuthAPI



Policy

AuthenticatedClient

Resources

pdacld

Figure 11. Authorization API: remote cache mode


External authorization capabilityIn some situations, the standard Tivoli Access Manager policyimplementations—ACLs and POPs—might not be able to express all theauthorization rules required by an organization’s security policy. Tivoli AccessManager provides optional external authorization capability to accommodate anyadditional authorization requirements.

The external authorization service allows you to impose additional authorizationcontrols and conditions that are dictated by a separate (external) authorizationservice module.

Extending the authorization serviceExternal authorization capability is automatically built into the Tivoli AccessManager authorization service. If you configure an external authorization service,the Tivoli Access Manager authorization service simply incorporates the accessdecision paths into its evaluation process.

Applications that use the authorization service—such as WebSEAL and anyapplication using the authorization API—benefit from the additional, but seamless,contribution of a configured external authorization service. Any addition to thesecurity policy through the use of an external authorization service is transparentto these applications and requires no change to the applications.

The external authorization service architecture allows the full integration of anorganization’s existing security service. An external authorization service preserves


PolicyServer

(pdmgrd)Master

AuthorizationPolicy


AuthAPI



Policy

AuthenticatedClient

Resources

Figure 12. Authorization API: local cache mode


a company’s initial investment in security mechanisms by allowing legacy serversto be incorporated into the Tivoli Access Manager authorization decision-makingprocess.

Imposing conditions on resource requestsAn external authorization service can be used to impose more specific conditionsor system-specific side effects on a successful or unsuccessful access attempt.

Examples of such conditions include:v Causing an external auditing mechanism to record the successful or unsuccessful

access attemptv Actively monitoring the access attempt and cause an alert or alarm whenever

unacceptable behavior is detectedv Conducting billing / micro-payment transactionsv Imposing access quotas on a protected resource

The authorization evaluation processAn authorization decision that incorporates an external authorization server takesplace in the following manner:1. If a trigger condition is met during the course of an access decision, the

external authorization services that have been configured for that condition areeach called in turn to evaluate their own external authorization constraints.Invocation of the external authorization service occurs regardless of whether ornot the necessary permission is granted to the user by the Tivoli AccessManager authorization service.

2. Each external authorization service returns a decision of permitted, denied, orindifferent.When “indifferent” is returned, the external authorization service hasdetermined that its functionality is not required for the decision process andthat it does not participate.

3. Each external authorization service decision is weighted according to the levelof importance that its decision carries in the process.The weighting of individual external authorization services is configured whenthe service plug-in is loaded.

4. All authorization decision results are summed and combined with the decisionmade by the Tivoli Access Manager authorization service. The resultingdecision is returned to the caller.

ExampleFigure 13 on page 22 illustrates an authorization decision involving a third-partyapplication server and an external authorization service.


In this example, the purpose of the external authorization service is to impose aquota restriction on how often the photo-quality printer resource can be accessed.

The service implementation imposes a limit on the number of job submissions thatany one person can make to this printer in one week. An external authorizationservice trigger condition has been attached to the photo printer resource so that theexternal authorization service is invoked anytime that the photo printer isaccessed.

The external authorization service has been loaded with the default decisionweighting of 101, which overrides any decision made by the Tivoli Access Managerauthorization service, should it need to do so.1. The third-party application server receives a request from a client for access to

an online photo printing resource. The client is a member of the appropriategroup GraphicArtists and so is normally permitted to submit jobs to theprinter.

2. The third-party application server first consults the Tivoli Access Managerauthorization service to determine whether the requesting user has permissionto submit jobs to the printer.

3. The authorization service checks the access permissions on the target requestedobject and compares these with the capabilities of the requesting user:group GraphicArtists rx

In the ACL on the printer resource, the x permission grants any user in theGraphicArtists group access to the resource. Therefore, the authorizationservice grants the user permission to submit the job.

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 13. External authorization service with a third-party application server


4. Because the photo printer resource is being accessed and an externalauthorization service trigger condition was attached to this object, a request isalso made to the external authorization service configured for that triggercondition.The external authorization service receives all of the Access DecisionInformation (ADI) that was passed in with the original access decision check bythe third-party application server.

5. The external authorization service consults the record of previous accessesmade by this user. If the requesting user has not exceeded the quota for theweek, it returns an access decision of “indifferent.”The implication is that the external authorization service is indifferent to therequest and has no intention of participating in the access decision because itsconditions for denying access have not been met.However, if the user has exceeded the quota, then the external authorizationservice returns a decision of “access denied.”For this example, it is assumed that the requester has exceeded the quota andthat the external authorization service detects this and returns an “accessdenied” decision.

6. The Tivoli Access Manager authorization service receives the “access denied”result from the external authorization service. It then takes this decision andweights it with the default external authorizations service weighting value of101.The results of the external authorizations service decision and the decisionmade by the Tivoli Access Manager authorizations service are combined. Theresult is “access denied” because the result of the external authorizationsservice (-101) outweighs that of the Tivoli Access Manager authorization service(100).

7. The third-party application server rejects the job submission to the photoprinter resource.

8. The third-party application 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 authorizations service:1. Write an external authorizations service plug-in module with an authorization

interface that can be referenced during authorization decisions.2. Register the external authorizations service with Tivoli Access Manager so that

Tivoli Access Manager authorization clients can load the plug-in service atinitialization time.

Registering the service sets a trigger condition for the invocation of the externalauthorizations service. When the trigger condition is encountered during anauthorization check, the external authorizations service interface is invoked tomake an additional authorization decision.

Deployment strategiesTivoli Access Manager allows you to implement an external authorizations servicein several ways:v Any number of external authorization servers can be added to your secure

domain to perform a variety of authorization evaluations. Each externalauthorizations service is loaded into the individual local-mode authorization APIclient application. Applications that can load external authorizations services


include the authorization server (PDAcld), other Tivoli Access Manager servers,and any authorization applications written by the customer.

v Remote-mode authorization API clients, which make requests to theauthorization server for authorization decisions, automatically make use of anyexternal authorizations service that are loaded by the authorization server.

v More than one external authorizations service can be called for any single triggercondition. In this case, the results of each external authorizations service isweighted accordingly and then the results are combined with the result of theTivoli Access Manager authorizations service.

v Trigger conditions can be placed on objects, using a POP trigger, such that anyrequest to an object, regardless of the operation that is being requested, triggersa call to the external authorizations services that are configured for the trigger.

v Trigger conditions can also be placed on the operations requested by a user. Forexample, an external authorizations service can be triggered specifically when auser requests a write operation to a protected resource, but not for any otheroperation. It is then possible to develop sets of operations for which one or moreexternal authorizations services in combination are triggered according the set ofoperations requested.

v The external authorizations services are implemented as dynamically loadablelibrary (DLL) modules. This greatly simplifies the task of external authorizationsservice development. There is no requirement to make remote requests to theexternal authorizations service and the overhead of making the call is equivalentto the overhead of a function call.

v The combination of the authorization API and an external authorizations serviceprovides a highly extensible and flexible solution for implementing complexsecurity policy.

Tivoli Access Manager base certificate and password managementThe Tivoli Access Manager base components use SSL for encryption, systemauthentication, and application-level authentication. SSL uses certificates foroperation. In the secure environment, pdmgrd acts as the certificate authority (CA)and is responsible for the creation and renewal of certificates. The Tivoli AccessManager runtime (pdrte) only relies on SSL server-side authentication and as such,does not require a client-side certificate. However, all of the Tivoli Access Managerservers such as pdmgrd, pdacld, and aznAPI servers rely on client-side certificatesto operate.

The servers use certificates to authenticate themselves. For example, when pdacldis communicating with pdmgrd, it presents its client-side certificate. In thisexample, pdmgrd can be considered the server and pdacld as the client. Thepdmgrd server verifies that the certificate is valid and is signed by a trusted signer(in this case pdmgrd itself, using the PDCA certificate). The pdacld server does thesame for the certificate presented by pdmgrd. As part of the Tivoli Access Managerapplication-level authentication, after pdmgrd determines that the pdacldcertificate is good, it tries to map that certificate to a Tivoli Access Manager user. Ifthe authentication succeeds, then the servers can begin communicating.

The certificates used by Tivoli Access Manager are kept in keyring database files(these have a .kdb extension). These files should be secured and protected by thestrictest operating system controls available because they contain the private keysfor the certificates in question. For example, the keyring database file for pdmgrdis ivmgrd.kdb and by default it is readable and writeable by only the ivmgr userand the ivmgr group.


Furthermore, to facilitate unattended server operation, there are files that containan obfuscated (not encrypted) version of the password to the keyring databasefiles. These are called stash files, which are denoted by a .sth file extension. Again,these files should be secured using OS measures. For pdmgrd, the stash file isivmgrd.sth and its permissions are the same as ivmgrd.kdb.

For security reasons, both the certificates and the keyring database file passwordscan be set to expire after a configurable amount of time. The default lifetime for acertificate is 365 days. The default lifetime for a keyring database file password is183 days. The fixed lifetime for the PDCA certificate is 20 years. Also by default,the Tivoli Access Manager components perform self-care; that is, they refresh thecertificates and passwords automatically while they are running.

However, if the servers are not running within a specified window of time, theircertificates or passwords can expire. If this is the case, a manual refresh isnecessary. Furthermore, if a certificate, password, or entire keyring database file iscorrupted, then to keep the Tivoli Access Manager domain secure, a manualrefresh is also warranted. For information on performing a manual refresh, see“Starting and stopping Tivoli Access Manager servers” on page 92.

Initial configurationThe certificates used by the Tivoli Access Manager components are created as partof their initial configurations. In a brand new Tivoli Access Manager installation,the pdmgrd server is the first server configured. As part of its configuration, thePDCA certificate is created and a personal certificate used by pdmgrd is createdand signed by the PDCA certificate. Both of these certificates are located in theivmgrd.kdb keyring database file. Also, as part of the pdmgrd configuration, theruntime keyring database file, pd.kdb, is created and the PDCA certificate isinserted into it as a trusted certificate.

When new systems are added to the Tivoli Access Manager domain, pdrte isconfigured first. Again, as part of this configuration, the system pd.kdb and pd.sthfiles are created and the PDCA certificate is included in the keyring database file asa trusted certificate.

When new aznAPI servers (such as pdacld or WebSEAL) are configured, thesvrsslcfg tool (or equivalent API) is run. This tool creates a keyring database file(such as pdacld.kdb) and places a personal certificate for the server in it. The toolalso inserts the PDCA certificate as a trusted certificate in the keyring database file.These two certificates are obtained from pdmgrd and are transported to the clientmachine over SSL using the runtime keyring database file.

Keyring database file and stash file renewal informationThe following table lists the components and their associated keyring and stashfiles. It also describes how they are created and refreshed.


Component Keyring/StashFile

How it iscreated

Processes thatautomaticallyupdates thekeyring file orpassword, orboth

Tool for manualupdate

pdrte pd.kdb pd.sth(does notcontain aclient-sidecertificate)

During the pdrteconfiguration

Invocations ofpdadmin1

bassslcfg-chgpwd

pdmgrd ivmgrd.kdbivmgrd.sth

During pdmgrdconfiguration

Runningpdmgrd1,2

mgrsslcfg-chgpwd3andmgrsslcfg-chgcert3

pdacld ivacld.kdbivacld.sth

During pdacldconfiguration

Running pdacld1 svrsslcfg-chgpwd4 andsvrsslcfg-chgcert5

aznAPI server aznAPI.kdbaznAPI.sth(name isconfigurable)

Runningsvrsslcfg -config

Runninginstance of theaznAPI server1

svrsslcfg-chgpwd6andsvrsslcfg-chgcert7

Notes:v 1 - Automatic certificate and password refresh can be turned off by setting the

attribute [ssl], ssl-auto-refresh to no in the respective configuration (.conf) file.v 2 - Because pdmgrd also acts as the CA for the secure domain, it must be

recycled after a refresh. It continues to operate normally until it is recycled,except it is not be able to issue or renew certificates for other servers until it isrecycled. The pdmgrd.log file contains a message stating when the server needsto be restarted.

v 3 - Before running this command, the pdmgrd server must be stopped.v 4 - Before running this command, the pdacld server must be stopped.v 5 - Before running this command, the pdmgrd server must be running and the

pdacld server must be stopped.v 6 - Before running this command, the aznAPI server must be stopped.v 7 - Before running this command, the pdmgrd server must be running and the

aznAPI server must be stopped.

Determining trustEach of the keyring database files also contains a list of trusted CAs. For TivoliAccess Manager, every keyring database file (except ivmgrd.kdb) has the PDCAcertificate as a trusted CA. The CA is the certificate that is used to sign all of theother Tivoli Access Manager certificates. This CA is created during pdmgrdconfiguration and is placed in the ivmgrd.kdb file. It is extremely important toprotect the ivmgrd.kdb file to keep the PDCA certificate’s private key from beingcompromised. If it is compromised, then it must be regenerated. It this happens,then every keyring database file and every certificate in the secure domain needsto be regenerated as well. The steps for performing this action are:


1. Regenerate the PDCA certificate (and pdmgrd server certificate) by generating anew ivmgrd.kdb file using mgrsslcfg -unconfig and then mgrsslcfg -config(pdmgrd must be stopped).

2. Regenerate all pdrte runtimes within the domain by first running bassslcfg-unconfig. Next, obtain the CA certificate. If auto-download of the CAcertificate is on and pdmgrd is running, then the CA certificate is obtained byrunning bassslcfg -getcacert -h pdmgrd hostname -c certificate file name. Ifauto-download is off, then the base-64 DER encoded version of the PDCAcertificate must be hand copied to the machine. This file is stored aspdcacert.b64 on the pdmgrd machine. Finally, run bassslcfg -config tocomplete the pdrte configuration.

3. Regenerate any pdacld keyring files within the domain by running svrsslcfg-chgpwd and svrsslcfg -chgcert (pdmgrd must be running). These commandsupdate both the server certificate for pdacld and its trusted certificate (the newPDCA certificate).

4. Regenerate any other aznAPI server keyring files within the domain byrunning svrsslcfg -chgpwd and svrsslcfg -chgcert (pdmgrd must be running).These commands update both the server certificate for the server and itstrusted certificate (the new PDCA certificate).

Certificate revocationIf a server’s keyring database file or certificate is compromised, it can be revokedby running the appropriate chgcert command. This effectively generates a newcertificate making the old certificate invalid. For example, if a pdacld has itscertificate compromised, then running svrsslcfg -chgcert generates a new certificatefor that file and makes the compromised certificate invalid. Also, by running thesvrsslcfg -unconfig command, a certificate no longer authenticates within TivoliAccess Manager.

Additional considerationsAdditional considerations for keyring database file and stash file renewal are asfollows:v If a certificate and the password to the keyring database file containing that

certificate are both expired, then the password must be refreshed first. Forexample, for pdacld, run svrsslcfg -chgpwd and then svrsslcfg -chgcert. This isnecessary because a valid password is needed to open the keyring database fileto get to the certificate.

v The value for the lifetime of a certificate is controlled by the value of theivmgrd.conf, [ssl], ssl-cert-life attribute when pdmgrd is started. Any certificatesissued or renewed use this value. To increase or decrease this value, change thevalue and restart pdmgrd. The new value is in effect only for certificates issuedor renewed from that point on.

v For automatic password renewal, the value for the lifetime of a password iscontrolled by the value of the [ssl], ssl-pwd-life attribute in effect when the serveris started. For manual password renewal, the value is dictated by the valuesupplied to the chgpwd command. This value is also written into theappropriate configuration file.

v Tivoli Access Manager servers can also communicate with LDAP using SSL. Inthe standard configuration, this communication uses server-side authenticationonly. Therefore, the Tivoli Access Manager server needs only the CA certificatethat signed the LDAP server certificate or the LDAP server certificate itself. Theexpiration and management of these certificates is not handled by Tivoli Access


Manager. However, it is possible to include the LDAP certificate in the keyringdatabase file for an aznAPI server by running svrsslcfg -config and using the -Coption.

v After running bassslcfg -config, it might be necessary to change the permissionsof pd.kdb and pd.sth.

v The configuration files mentioned are generally found in the install_dir/etcdirectory. For example, on AIX the pdmgrd, pdacld, and runtime configurationfiles are found in /opt/PolicyDirector/etc/ivmgrd.conf,/opt/PolicyDirector/etc/ivacld.conf, and /opt/PolicyDirector/etc/pd.confrespectively. Similarly, the keyring database files and stash files can be found inthe install_dir/keytabs directory.

Default administration users and groupsAt installation, Tivoli Access Manager provides several important administrationgroups. By default, these users and groups are given special permissions to controland manage all operations in the secure domain. (This default security policy isdefined by the ACLs created during installation.)

The following sections detail the specific roles assigned to each of these users andgroups at installation time, and explain how to create administration users.

group iv-adminThis group represents the administrator group. All members of this group areconsidered administrators of the secure domain by the default policy.

You can easily place users into an administration role by adding them to theiv-admin group. The danger with this procedure is that as soon as a user becomesa member of this group (with the default ACLs), that user has full rights toperform administration operations on any object in the entire namespace withinthe default policy.

The default policy for this group can be changed by delegating managementpermissions to other users and revoking some or all management permissions fromthe iv-admin group.

When the policy server is configured, the sec_master user is created and added tothe iv-admin group. It is the combination of group memberships that grantssec_master complete rights for all operations within the secure domain but onlywithin the default policy. Sec_master does not have rights to new groups createdoutside of the default policy unless it is added as a user or a member of a group.

group ivmgrd-serversThis group contains the policy server. Tivoli Access Manager requires that exactlyone policy server exist in the secure domain.

Because most management requests made by the Web Portal Manager, pdadminutility, or admin API are executed using the policy server to the target server, thepolicy server must have permission to perform the request at the target server. Forthis reason, this group is granted server administration permission (s) in thedefault management ACL and list (l) permission throughout the Web space.


Creating administration usersYou can create administration accounts with varying degrees of responsibility.Responsibility is delegated to administrators through strategically placedadministration ACLs. The following list illustrates possible administration roles:v ACL administration responsibilities

The ACL administrator can control all, or part, of a protected object namespaceregion, depending on where the administration ACL is placed. Theadministrator’s ACL entry could contain the browse (b), attach (a), and traverse(T) permissions, plus any other permissions appropriate for operations onobjects in that region.The administrator can use the Web Portal Manager, pdadmin utility, or adminAPI to attach (a) ACLs to objects in the designated namespace using the existingset of ACL templates. This administrator would not require permissions tocreate, modify, or delete ACL templates.

v ACL policy responsibilities

The ACL policy administrator should be responsible for controlling the creationand modification of all ACL templates used in the secure domain. The ACLpolicy administrator should be granted delete (d), browse (b), modify (m), andview (v) permission on the /Management or /Management/ACL object.This ACL policy administrator can create new ACL templates using the modify(m) permission. As the creator of a new template, the administrator becomes, bydefault, the first entry in the new ACL template, with TcmdbsvaBl permissions.The control permission (c) effectively gives the administrator ownership of theACL, and therefore the ability 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 the ACL from the list of templates.You cannot delete an ACL template unless you are the owner of that ACL.

v Server management responsibilities

This administrator is granted delete (d), modify (m), server administration (s),and view (v) permissions on the /Management/Server object. This administratorcan perform operations affecting the Tivoli Access Manager servers.

v Authorization action responsibilities

This administrator is granted delete (d) and modify (m) permissions on the/Management/Action object. This administrator can create or delete allpermissions created for third-party applications.

Example administration ACL templatesThe following example illustrates how a user gains administration rights.v The following ACL on /WebSEAL gives administration rights to user adam:

user sec_master abcTdmlrxgroup iv-admin abcTdmlrxgroup webseal-servers gTdmlrxgroup ivmgrd-servers Tluser adam abcTdmlrxany-other Trxunauthenticated Trx


Chapter 2. Managing the protected object space

A secure domain contains physical resources that usually need some level ofprotection. Resources can include files, directories, and printer services. TivoliAccess Manager uses a virtual representation of these resources called theprotected object space.

Resources can be protected by attaching ACL and POP policies to the objectrepresentations of these resources. This chapter discusses the protected object spaceand how you can create extensions to the object space to support customapplication requirements.

This chapter contains the following sections:v “The protected object space” on page 31v “Defining a database object space” on page 33

The protected object spaceThe Tivoli Access Manager security model depends on ACL and POP policies toprovide fine-grained protection for these resources. A corporate security policy isimplemented by the strategically applying custom ACL and POP policies to thoseresources requiring protection. The Tivoli Access Manager authorizations servicemakes decisions to permit or deny access to resources based on user credentialsand the specific permissions and conditions set in the ACL and POP policies.

In order to apply ACL and POP policies and allow the authorizations service toperform its security checks, Tivoli Access Manager uses a virtual objectrepresentation of secure domain resources called the protected object space.

As a Tivoli Access Manager security administrator, you can use the wpm or thepdadmin utility to attach ACL and POP policies to the logical objects in the objectspace.

Elements of the protected object spaceThe Tivoli Access Manager protected object space is the logical and hierarchicalportrayal of resources belonging to a secure domain. Objects that appear in thehierarchical object space represent actual physical resources.v System Resource – the actual physical file, network service, or applicationv Protected Object – the logical representation of an actual system resource used

by the authorizations service, the wpm, and other Tivoli Access Managermanagement utilities

The protected object space uses two types of objects:v Container objects

Container objects are structural designations that allow you to organize theobject space hierarchically into distinct functional regions. Container objectscontain resource objects.

v Resource objects


Resource objects are the representations of actual resources (such as services,files, and programs) in your secure domain.

Protected object space hierarchyThe structural top, or start, of the protected object space is the root containerobject. The symbol for root is the forward slash ( / ).

The following object space categories follow the root object:v Web objects ( /WebSEAL container)

The WebSEAL container object is the root of the logical Web space of the securedomain. All HTTP operations are authorized against some object in this sub-tree.Web objects represent anything that can be addressed by a URL. This includesstatic Web pages and dynamic URLs that are converted to database queries orsome other type of application invocation by a Web-to-application gateway.

v Tivoli Access Manager management objects ( /Management container)

The Management container object is the root of the logical space controlling allTivoli Access Manager management operations. Management objects representthe services required to define users and groups, and set security policy. Thesetasks can be performed using the wpm or the pdadmin utility.Subdivisions of the /Management region include:– User management (/Users)– Group management (/Groups)– GSO management (/GSO)– Server management (/Server)– ACL policy (/ACL)– POP (/POP)– Configuration authorization control (/Config)– Third-party authorization control (/Action)– Authorization database replication control (/Replica)

Tivoli Access Manager supports delegation of certain management activities andcan restrict an administrator’s ability to set security policy to a subset of theobject space.

v User-defined objects

container objects

resource objects

Figure 14. Tivoli Access Manager protected object space


These objects represent customer-defined tasks or resources protected bythird-party applications that use the authorization API to make calls to the TivoliAccess Manager authorizations service.

User-defined object space for third-party applicationsTivoli Access Manager 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 application that is usingTivoli Access Manager. WebSEAL, for example, has its own object space (/WebSEAL).Tivoli Access Manager stores management objects in the /Management object space.

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

/WebSEAL/Management

Tivoli Access Manager and third-party applications make calls to theauthorizations service through the authorization API. Two necessary steps arerequired to integrate a third-party application with the authorizations service:v Describe the third-party application’s object space.v Define the third-party application’s action groups and actions.v Apply permissions on any objects requiring protection.

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

Defining a database object spaceTivoli Access Manager allows you to extend its authorization services to objectsbelonging to a user-defined third-party object space. Two necessary steps arerequired to integrate a third-party object space with Tivoli Access Manager:v Describe the third-party application’s object space to Tivoli Access Manager.v Define the third-party application’s action groups and actions.

Figure 15. Regions of the Tivoli Access Manager protected object space

Chapter 2. Managing the protected object space 33

v Apply ACL and POP policies to any objects requiring protection.

The pdadmin objectspace commands allow you to easily create user-defined objectspace regions and manage the objects contained in these spaces. User-definedobject spaces created with these commands are dynamic because they can beupdated while Tivoli Access Manager is running.

Creating a new user-defined container objectUse the pdadmin objectspace and object commands to manage user-defined objectspaces. The objectspace command creates a container type object.

Note: The default Tivoli Access Manager object spaces (/WebSEAL and /Management)cannot be controlled with the pdadmin objectspace commands.

Syntax:pdadmin> objectspace create name description type

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

The description appears in the wpm.

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 – nonexistent object11 – container object12 – leaf object13 – port14 – application container object15 – application leaf object16 – management object17 – unused

When creating an object, a type must be specified. You can select an appropriatecategory, or use any number to designate the object type and assign meaning to it.

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

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

Administration notes:v It is best to create a separate object space for each third-party application.v You must define the new object space before you can add objects.v The root of the object space—created at the same time the object space is

defined—automatically has the ispolicyattachable attribute set.


Creating and deleting objectsAs soon as an object space has been created, you can populate it with objects.

Use the pdadmin object commands to manage user-defined objects.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 in the objectspace, beginning with an existing object space name.

Description The text description of the object.

Type The type of the object to be created. Used by the Web portalmanager to display an appropriate icon.

ispolicyattachable Indicates if a POP can be attached to the object. If set to “no”,the object inherits policy from above. Used to force childobjects to use the same 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

Administration notes:v Child objects are not moved when you change the name of a parent object.

Child objects can therefore be left without parent objects. You must move allchild objects when you change the name of a parent object.

v If the ispolicyattachable field is left out in the pdadmin object create command,the utility assumes that you intended to use the objectspace create command.An objectspace is created rather than an object.

Chapter 2. Managing the protected object space 35

Chapter 3. Using access control policies

Tivoli Access Manager uses a virtual representation of the resources in the securedomain called the protected object space. Resources can be protected by definingspecial security policies and attaching these policies to the object representation ofthis resource in the protected object space.

The policy type that defines who has access to an object, and what operations canbe performed on the object, is known as an access control list (ACL) policy. ACLpolicies are used to help stamp an organization’s security policy onto the resourcesbelonging to the secure domain.

This chapter contains the following sections:v “The ACL policy” on page 37v “ACL entry syntax” on page 38v “How the authorizations service uses ACL policies” on page 41v “Evaluating an ACL” on page 43v “Sparse ACL model” on page 44v “Creating extended ACL actions and action groups” on page 48v “ACL policies and the protected object space” on page 51v “Management permissions” on page 52v “Object and object space permissions” on page 58v “Default administration ACL policies” on page 58

The ACL policyAn access control list policy (ACL) is a method used by Tivoli Access Manager toprovide fine-grained protection to resources in the secure domain.

An ACL policy is a set of rules, or permissions, that specify the conditionsnecessary to perform an operation on a protected object. An ACL policy identifiesthe operations permitted on a protected object and lists the identities (users andgroups) who can perform those operations.v User and group identities are defined in the Tivoli Access Manager registry.v The protected object space and ACL policies are defined in the master

authorization database.

Each ACL policy has a unique name or label. Each ACL policy can be applied toone or more objects.

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

ACL policy entriesAn ACL policy consists of one or more entries describing:v The names of users and groups whose access to the object is explicitly controlledv The specific operations permitted to each user, group, or role


v The specific operations permitted to the special any-other and unauthenticateduser categories

A user represents any authenticated Tivoli Access Manager identity. Typically, usersrepresent network users or application servers.

A group is a collection of one or more users. A network administrator can usegroup ACL entries to easily assign the same permissions to multiple users. Newusers to the secure domain gain access to objects by becoming members ofappropriate groups. This eliminates the need to create new ACL entries for everynew user. Groups can represent organizational divisions or departments within asecure domain. Groups are also useful in defining roles or functional associations.

Users and groups are collectively referred to as entities.

User and group entries in ACLs are actually stored using a universally uniqueidentifier (UUID). The UUID provides extra security in the case where a user orgroup is deleted from the domain and then re-created with the same name. Forexample, even though a new user has the same name as the deleted user, TivoliAccess Manager allocates a new UUID to this user. Because the UUID is new, anyexisting ACLs that refer to the old user name do not grant any rights to the newuser. Stale UUIDs in ACLs (from deleted users and groups) are silently removedby the policy server (pdmgrd).

You can use the pdadmin utility or the Web portal manager to create, modify, anddelete ACL entries.

Creating and naming ACL policiesYou can use the Web Portal Manager, or the pdadmin acl create command, tocreate a unique ACL policy and save it with a name. You can then apply securitypolicy by attaching the ACL to objects in the protected object space.

The ACL becomes a single source policy (like a formula or recipe) containing thespecific entries that provide the correct level of protection for all objects associatedwith it. If the security policy requirements change, you edit only the single ACL.The new security definition is instantly implemented for all objects affected by thatACL.

ACL entry syntaxAn ACL entry contains either two or three attributes, depending on the ACL entrytype, and appears in the following format:

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

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

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

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

ACL(containing multiple

entries)

Figure 16. Access control list for a Web page object


v Type – the entity category (user or group) for which the ACL was createdv ID (Identity) – the unique identifier (name) of the entity

The ID attribute is not required for the any-other and unauthenticated ACLentry types

v Permissions (or actions) – the set of operations permitted on the object by thisuser or group

Most permissions dictate the client’s ability to perform a specific operation on theresource.

In the above example, the user adam (type = user, ID = adam) has permission toread (view) the object protected by this ACL policy. The r permission allows theread operation. The T permission enforces the traverse rule.

Type attributeAn ACL entry type identifies the user, group, or special entity for a specific ACLentry. There are four ACL entry types.

Type Description

user Sets permissions for a specific user in the secure domain. The user must be a memberof the secure domain with an account in the registry. The user entry type requires auser name (ID). The entry format is: user ID permissions

For example:

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

group Sets permissions for all members of a specific group in the secure domain. The groupentry type requires a group name (ID). The entry format 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 is required. The entryformat is: any-other permissions

For example:

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

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

Type ID Permissions

Figure 17. ACL entry attributes

Chapter 3. Using access control policies 39

Type Description

unauthenticated Sets permissions for those users who have not been authenticated by the securityserver. No ID designation is required. The entry format is: unauthenticatedpermissions

For example:

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

This ACL entry is a mask (a bit-wise “and” operation) against the any-other ACL entryto determine the permission set. A permission for unauthenticated is granted only ifthe permission also appears in the any-other entry. For example, the followingunauthenticated ACL 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 or group entry type.IDs must represent valid users or groups or both created for the secure domainand 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 and unauthenticated ACLentry types.

Permissions (actions) attributeEach ACL entry contains a set of permissions (or actions) that describes the specificoperations permitted on the object by the user or group

ACL policies control protected resources in the following ways:v A user’s ability to perform operations on protected objectsv An administrator’s ability to change access control rules on the object and any

subobjectsv Tivoli Access Manager’s ability to delegate user’s credentials

Note: ACL permissions are context-sensitive — the behavior of certain permissionsvaries according to the region of the protected object space in which they areapplied. For example, the m permission has a different meaning on aWebSEAL object than on a management object.


Default Tivoli Access Manager permissions (actions)Tivoli Access Manager defines seventeen default permissions (actions). The WebPortal Manager divides these permissions into three categories.

Base Generic Third-partyapplication

a 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 POP (protected objectpolicy)

Base

c Control Base

d Delete Generic

g Delegation Base

l List directory Third-party application

m Modify Generic

N Create Base

r Read Third-party application

s Server administration Generic

t Trace Base

T Traverse Base

v View Generic

W Password Base

x Execute Third-party application

Tivoli Access Manager provides the capability to define many more additionalpermissions (actions) for use by third-party applications. For more information, see“Creating extended ACL actions and action groups” on page 48.

How the authorizations service uses ACL policiesTivoli Access Manager relies on ACL policies to specify the conditions necessary toperform an operation on a protected object.

When an ACL is attached to an object, entries in the ACL specify what operationsare allowed on this object and who can perform those operations.

Tivoli Access Manager uses a default set of permissions that cover a wide range ofoperations. Permissions are represented by single printable ASCII characters (a-z,A-Z). Each permission is displayed (by pdadmin or the Web portal manager) witha label describing the operation it governs. In addition, the Web Portal Managergroups the ACLs 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 that are performedon protected objects. Tivoli Access Manager requires these applications to makecalls into the authorization service before the requested operation is allowed toprogress. This call is made through the authorization API for both Tivoli AccessManager services and third-party applications.

The authorization service uses the information contained in the ACL to make asimple yes or no response to the question: Does this user (group) have the rpermission (for example) to ‘view’ the requested object?

It is important to note that the authorization service knows nothing about theoperation requiring the r permission. All it cares about is the presence, or not, ofthe r permission in the ACL entry of the requesting user or group.

This is actually a very powerful feature of the authorization service. The service iscompletely independent of the operations being requested. This is why it is easy toextend the benefits of the authorization service to third-party applications.

Requirements for custom permissionsDefault Tivoli Access Manager permissions (actions) are available to third-partyapplications. If a third-party application makes use of a default Tivoli AccessManager permission, the associated operation should very closely match that of theactual operation normally performed by Tivoli Access Manager. For example, rshould be used only by an operation that requires a read-only access to a protectedobject.

Note: A third-party application can use a default Tivoli Access Managerpermission for a completely unrelated operation because the authorizationservice does not know or care about the operation. However, this situationwould cause difficulty for an administrator who would have to distinguishbetween two dissimilar uses of the same permission.

If a third-party application uses an operation that is not well represented by anythe default permissions, Tivoli Access Manager allows you to define a newpermission (action) that can be used by this application and recognized by theauthorization service.

See “Creating extended ACL actions and action groups” on page 48.

Custom action exampleIn this example, there is a requirement to protect a certain printer device fromunauthorized use. A third-party print spooling service is written with theauthorization API so that it can call the authorization service to perform ACLchecks on requests made to the printer.

The standard Tivoli Access Manager permissions do not include an obviouspermission for protecting printers. However, the printer can be protected by anewly created permission (p in this example).

An ACL policy is attached to the printer object. If a user requests the use of theprotected printer, that user must have an ACL entry containing the p permission.The authorizations service returns a favorable response if the p permission ispresent and the printing operation proceeds. If the authorizations service finds no


existence of a p permission for that user, the printing operation is not allowed toproceed.

Evaluating an ACLTivoli Access Manager follows a specific evaluation process to determine thepermissions granted to a particular user by an ACL. When you understand thisprocess, you can determine how best to keep unwanted users from gaining accessto resources.

Evaluating authenticated requestsTivoli Access Manager evaluates an authenticated user request in the followingorder:1. Match the user ID with the ACL’s user entries. The permissions granted are

those in the matching entry.Successful match: evaluation stops here. Unsuccessful match: continue to the next step.

2. Determine the groups to which the user belongs and match with the ACL’sgroup entries:If more than one group entry is matched, the resulting permissions are a logical“or” (most permissive) of the permissions granted by each matching entry.Successful match: evaluation stops here. Unsuccessful match: continue to the next step.

3. Grant the permissions of the any-other entry (if it exists).Successful match: evaluation stops here. Unsuccessful match: continue to the next step.

4. An implicit any-other entity exists when there is no any-other ACL entry. Thisimplicit entry grants no permissions.Successful match: no permissions granted. End of evaluation process.

Evaluating unauthenticated requestsTivoli Access Manager evaluates an unauthenticated user by granting thepermissions from the ACL’s unauthenticated entry.

The unauthenticated entry is a mask (a bitwise “and” operation) against theany-other entry when permissions are determined. A permission forunauthenticated is granted only if the permission also appears in the any-otherentry.

Because unauthenticated depends on any-other, it makes little sense for an ACL tocontain unauthenticated without any-other. If an ACL does containunauthenticated without any-other, the default response is to grant no permissionsto unauthenticated.

PrintSpoolerService


Printer ACL

AuthznPolicy

Database

API

user michael p

Can I use thisprinter?

"YES"

Figure 18. Custom print spooler action


Example ACL entriesYou set permissions for specific users and groups by specifying the appropriateACL entry type. In the following example, the group documentation has fullaccess privileges:group documentation --bcg--Tdmsv--lrx

You can restrict access to other authenticated users in the secure domain (notbelonging to the documentation group) by using the any-other entry type:any-other -------T-------rx

You can further restrict access to the unauthenticated entry type for users who arenot members of the secure domain.unauthenticated -------T-------r-

Note: Without an unauthenticated ACL entry, unauthenticated users cannot accessany secure documents within the secure domain.

Sparse ACL modelTo secure network resources in a protected object space, each object must beprotected by an access control list (ACL) policy.

You can assign an ACL policy to an object in one of two ways:v Attach an explicit ACL policy on the object.v Allow the object to inherit its ACL policy from a preceding container object in

the hierarchy.

Adopting an inherited ACL scheme can greatly reduce the administration tasks fora secure domain. This section discusses the concepts of inherited, or sparse ACLs.

ACL inheritanceThe power of ACL inheritance is based on the following principle: any objectwithout an explicitly attached ACL policy inherits the policy of its nearestcontainer object with an explicitly set ACL. In other words, all objects withoutexplicitly attached ACLs inherit ACLs from container objects with explicitlyattached ACLs. A particular chain of inheritance is broken when you attach anexplicit ACL on an object.

ACL inheritance simplifies the task of setting and maintaining access controls on alarge protected object space. In a typical object space, you need to attach only afew ACLs at key locations to secure the entire object space; hence, it is called asparse ACL model.

A typical object space begins with a single explicit ACL attached to the rootcontainer object. The root ACL must always exist and can never be removed.Normally, this is an ACL with very little restriction. All objects located in the objectspace inherit this ACL.

When a region or subtree in the object space requires different access controlrestrictions, you attach an explicit ACL at the root of that subtree. This interruptsthe flow of inherited ACLs from the primary object space root to that subtree. Anew chain of inheritance begins from this newly created explicit ACL.


The default root ACL policyTivoli Access Manager checks inheritance beginning with the root of the protectedobject space. If you do not explicitly set ACLs on any other objects in the tree, theentire tree inherits this root ACL.

There is always an explicit ACL policy set at the root of the protected object space.An administrator can replace this ACL with another ACL containing differententries and permission settings. But the root ACL can never be completelyremoved.

The root ACL policy is explicitly set during the initial Tivoli Access Managerinstallation and configuration.

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

Traverse permissionTivoli Access Manager access control depends on two conditions.1. The ACL that controls the requested object must contain appropriate 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 applied only to container objects in the protected objectspace. The traverse permission specifies that a user, group, any-other, orunauthenticated identified in the ACL entry has permission to pass through thiscontainer object in order to gain access to a protected resource object below in thehierarchy.

A protected object is accessible to a requester if the requester possesses the traversepermission on each ACL attached to container objects above the requested resourceon the path towards root and including root.

Figure 19 on page 46 illustrates how the traverse permission works. Within theACME Corporation, there is an Engineering container object (directory), which alsocontains a TechPubs container object (subdirectory). User kate, a member of theSales department, requires traverse to the Engineering/TechPubs directory toreview a release note file. The administrator provides traverse for any-other at theroot. The administrator provides traverse for group sales on the Engineeringdirectory. The TechPubs directory inherits the ACL from the Engineering directory.Although Kate has no other permissions in these two directories, she can pass(traverse) through these directories in order to access the release_note file.Because this file has read permission for user kate, she can view the file.


You can easily restrict access to the hierarchy below a given container object —without resetting individual permissions on these objects. Simply remove thetraverse permission from the appropriate ACL entry. Removing traverse permissionon a directory object protects 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 on theEngineering directory, Kate could not access the release note file, even though shehas read permission for the file.

Resolving an access requestInheritance begins with the root ACL and impacts all objects in the object spaceuntil it reaches an object with an explicit ACL. At this point, a new chain ofinheritance begins.

Objects below an explicitly set ACL inherit the new access controls. If you deletean explicit ACL, access control for all objects reverts back to the nearest directoryor container object with an explicitly set ACL.

When a user tries to access a secure object (such as a Web document), Tivoli AccessManager checks whether the user has the permissions to access the object. It doesthis by checking every object along the object hierarchy for the proper inherited orexplicitly set permissions.

A user is denied access to an object if any directory or container object in thehierarchy above does not include the traverse permission for that user. Access isalso denied if the target object does not contain sufficient permissions to performthe requested operation.

In order to succeed an access check, the requestor must have both the following:v Permission to traverse the path to the requested object.v Appropriate permissions on the requested object.

The process of resolving whether a user can read (view) an object is as shown:

Engineering/Sales/

TechPubs/

release_note

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

(ACL inherited)

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

ACME Corporation

root

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

Figure 19. Traverse permission


/acme/engineering/project_Y/current/report.html

Tivoli Access Manager checks for the following:1. Traverse permission on the explicitly set root ACL (/).2. Traverse permission on any explicit ACLs attached to the directories:

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 of these pointsalong the object hierarchy.

Applying ACL policies to different object typesPermissions for a variety of operations can be set in an ACL policy. Only a subsetof these possible operations might be relevant for a specific object to which theACL is attached.

The reason for this behavior is related to the two features of Tivoli Access Managerthat are designed to make administration easier:v ACL policiesv ACL inheritance

ACL policies allow you to attach the same ACL definition to multiple objects in theprotected object space. The ACL definition consists of enough entries to meet therequirements of all objects to which the ACL is applied; however, each individualobject might be affected by only a few of the entries.

In the ACL inheritance model, any object without an attached explicit ACL policy“inherits” the policy definitions from the nearest ACL applied to an object above itin the hierarchy.

In summary, an ACL policy has to describe the necessary permissions for all objecttypes that it is applied to — and not just the object that it is attached to.

ACL policy inheritance exampleFigure 20 on page 48 illustrates the impact of a mixture of inherited and explicitACLs in a corporate object space.

A corporate object space has a general security policy set at the root object. Root isfollowed by the /WebSEAL container object and individually controlled departmentalsub-trees.

In this example, the sales group is given ownership of their departmental subtree.Note that the ACL on this subtree no longer acknowledges the unauthenticated orany-other entry types.

The year-to-date sales file (ytd.html) has an explicit ACL that grants readpermission to members of the sales-vp group (who are also members of the salesgroup).

Note: This ACL scheme need not be changed with the addition or subtraction ofusers within the secure domain. New users are simply added to theappropriate groups. Likewise, users can be removed from those groups.


Guidelines for a secure object spacev Set high-level security policy on container objects at the top of the object space.

Set exceptions to this policy with explicit ACLs on objects lower in the hierarchy.v Arrange your protected object space so that most objects are protected by

inherited, rather than explicit, ACLs.Inherited ACLs simplify the maintenance of your tree because they reduce thenumber of ACLs you must maintain. This lower maintenance reduces the risk ofan error that could compromise your network.

v Position new objects in the tree where they inherit the appropriate permissions.Arrange your object tree into a set of subtrees, where each subtree is governedby a specific access policy. You determine the access policy for an entire subtreeby setting an explicit ACL at the root of the subtree.

v Create a core set of ACL policies and reuse these ACLs wherever necessary.Because an ACL policy is a single source definition, any modifications to thepolicy impacts all objects associated with this ACL.

v Control user access through the use of groups.It is possible for an ACL to consist of only group entries. Access to an object byindividual users can be efficiently controlled by adding users to or removingusers 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.

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 20. ACL inheritance example


Every Tivoli Access Manager permission is defined as an action. Seventeen actionsare predefined for immediate functionality (see “Default Tivoli Access Managerpermissions (actions)” on page 41). You can also define new actions for use bythird-party applications.

This section describes how to define action groups that serve as containers for anexpanded set of custom actions:v Each action group is capable of holding up to 32 action bits.v An action bit is made up of a letter: a-z, A-Z.v Each action bit character can be used only once within an action groupv You can reuse the same action bit in other action groups.v The default Tivoli Access Manager actions are stored in an initial predefined

action group called “primary”.

Tivoli Access Manager supports a total of 32 action groups (including the primaryaction group) for a total of 1024 individual actions.

Creating a new action groupUse the pdadmin action group create command to create a new action 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 listing and cannot bedeleted.

a A b B c g N T W

...

32

primary action group

Bits set for:group sales abNT

Figure 21. Primary action group

a A b B c g N T W

...

32

multiple action groups

Figure 22. Multiple action groups


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

Creating new actions in an action groupUse the pdadmin action create command to create a new action within an actiongroup.pdadmin> action create action_name action_label action_type action_group_name

Option Description

action_name Letter representing the action (permission).

action_label Descriptive label for this action. Appears in a pdadmin actionlist command and the Web Portal Manager.

action_type Action category (used by Web Portal Manager to groupcommon action bits together). Default categories include Base,Generic, and Third-party application.

action_group_name Action group where this new action belongs. If this argumentis not specified, the action is assigned to the “primary” actiongroup.

For example: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 38, ACL entries contain an entry type,a type ID (for user and group types), and the set of permitted action bits.

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

For example:

abgTr[groupA]Pq[groupB]Rsy[groupC]abv The first set of action bits (abgTr) represent permissions from the “primary”

(Tivoli Access Manager default) action group.v Action group A contains actions P and q.v Action group B contains actions R, s, and y.v Action group C contains actions a and b.v Note that action group C contains action bits that use the same letters as action

bits in the “primary” group.Because the action bits are associated with a specific action group (C), the a andb action bits have unique identities and can represent very different permissionsfrom the a and b action bits in the “primary” action group.


ExampleShow action groupspdadmin>pdadmin> action group list

primarytest-group

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-rootdefault-gsodefault-policydefault-configtestdefault-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 Kathy containing actions from action groups “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 object space and servetwo important security functions:1. You can use the container object’s ACL to define high level policy for all

subobjects within the region when no other explicit ACLs are applied.2. You can quickly deny access to all objects in a region by removing the traverse

permission from the container object’s ACL.

Root ( / ) container objectThe following security considerations apply for the root object:v The root object begins the chain of ACL inheritance for the entire protected

object space.


v If you do not apply any other explicit ACLs, the root object defines (throughinheritance) the security policy for the entire object space.

v Traverse permission is required for access to any object below root.

The traverse permissionThe traverse permission is a generic permission that applies throughout theprotected object space.

Operation Description

T traverse When applied to a container object, allows the requester tohierarchically pass through the container object on the wayto the requested resource object. It does not allow any othertype of access to the container object. Traverse is notrequired on the requested resource object itself.

Management permissionsThe Management region of the protected object space contains severalsubmanagement container objects that require specific sets of permissions:v “/Management/ACL permissions” on page 52v “/Management/Action permissions” on page 53v “/Management/POP permissions” on page 54v “/Management/Server permissions” on page 55v “/Management/Config permissions” on page 55v “/Management/Policy permissions” on page 55v “/Management/Replica permissions” on page 56v “/Management/Users permissions” on page 56v “/Management/Groups permissions” on page 57v “/Management/GSO permissions” on page 57

The following security considerations apply for the /Management region of theprotected object space:v The Management object begins the chain of ACL inheritance for the entire

Management region of the object space.v If you do not apply any other explicit ACLs, this object defines (through

inheritance) the security policy for the entire Management object space.v The traverse permission is required for access to /Management.

/Management/ACL permissionsThis object allows administration users to perform high-level ACL managementtasks that can impact the security policy for the secure domain.


a attach Attach ACL policies to objects; remove ACL policies fromobjects.

acl attachacl detach

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

acl modify



d delete Delete an existing ACL policy. The ACL entry for this usermust 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. This permissionmust be in an entry of an ACL attached to /Management/ACL.

acl findacl listacl show

You must create ACL administrator entries in the default ACL policy for the/Management/ACL object. The administrator’s ACL entry can contain any of theabove permissions. These permissions give the administrator powers to create newACL policies, attach ACLs to objects, and delete ACL policies.

An ACL administrator cannot modify an existing ACL unless there is an entry inthat ACL for the administrator containing the control (c) permission. Only theowner of an ACL can modify its entries.

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

For example, if sec_master is an administrator entry in the default-managementACL, with m permission, sec_master can create a new ACL policy. Usersec_master becomes the first entry in the new ACL, with Tcmdbsva permissions.

The control permission (c) gives sec_master ownership of the ACL and allowssec_master to modify the ACL. User sec_master could then grant administrationpermissions to other user entries in that ACL.

Ownership of the default-management ACL itself is given to both user sec_masterand group iv-admin by default.

The control permission (c)The control permission is a powerful permission that gives you ownership of anACL policy. Control allows you to modify the entries in the ACL. This means youhave the power to create entries, delete entries, grant permissions, and take awaypermissions.

The administrator who wants to delete an ACL from the list of ACL policies musthave an entry in that ACL and must have the control permission set in that entry.

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

The control permission is important only in the /Management/ACL space.

/Management/Action permissionsThis object allows administration users to manage custom actions and actiongroups. 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

Note: The following commands do not require special permissions:v action list

v action group list

Tivoli Access Manager provides authorization services to applications. Applicationsthat are part of the Tivoli Access Manager family include, for example, WebSEAL(for Web applications) and Tivoli Access Manager for Business Integration (formessaging applications).

Third-party applications can make calls to the authorizations service through theauthorization API. Two necessary steps required to integrate a third-partyapplication with the authorizations service include:v Define the application’s object spacev Define the application’s action groups and actionsv Apply permissions on objects (resources) needing protection

The administrator of a third-party application object space can use the pdadminutility to define new permissions and actions. The administrator must have the mand d Management/Action permissions to create and delete thesepermissions/actions.

/Management/POP permissionsThis object allows administration users to manage protected object policies. Allpermissions must appear in entries for ACLs on /Management/POP. Action tasks andassociated 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 Override the time-of-day POP attribute on an object.


/Management/Server permissionsThe /Management/Server container object of the protected object space allowsadministrators to perform server management tasks (when appropriate permissionsare set).

Server management controls are used to determine if a user has permission tocreate, modify, or delete a server definition. Server definitions contain informationthat allows other Tivoli Access Manager servers, particularly the policy server(pdmgrd), to locate and communicate with that server.

A server definition is created for a particular resource manager (such as WebSEAL)or authorization server (pdacld) as part of the installation process. The definitionfor a server is also deleted when the server is uninstalled.


s server Replicate authorization database.

server replicate

v view List registered servers and display server properties.

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 object space allowsadministrators to perform configuration management tasks (when appropriatepermissions are set).

The creation and deletion of server definitions happens automatically—theinstallation administrator does not have to perform any special steps to create adefinition. However, the administrator must be granted modify (m) permission onthe /Management/Config object in order to create the definition during installation.

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


m modify Configuration into a secure domain.

svrsslcfg -configsvrsslcfg -modify

d delete Unconfiguration.

svrsslcfg -unconfig

/Management/Policy permissionsThe /Management/Policy container object of the protected object space allowsadministrators to authorize the policy get and policy set commands (whenappropriate 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 object space controls thereplication of the authorization database. High-level controls on this object affectthe operation of the policy server and the security managers in the secure domain.

Replica management controls are used to determine what processes are allowed toread or update the master authorization policy database in order for replication totake place properly.

Controls and associated permissions include:


v view Read the master authorization database.

All Tivoli Access Manager servers that maintain a local replica of the authorizationdatabase — this includes all resource managers and authorization servers — mustbe granted view (v) permission on the /Management/Replica object. The replicationprocess requires that these processes be allowed to view and access entries out ofthe master authorization policy database. The Tivoli Access Manager installationautomatically grants read permission to any server requiring access to theauthorization policy database.

/Management/Users permissionsThis object allows administration users to manage user accounts. Action tasks andassociated 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 user to one ormore groups. Import group data from the user registry.

user createuser import

v view List user accounts and show user account details.

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

W password Reset and validate a user password.

user modify passworduser modify password-valid


The W permission allows password resets and is appropriate to give to helpdeskadministrators so they can assist users who have forgotten their passwords. Thispermission allows an administrator to reset the forgotten password and then usethe user modify password-valid command to set a value of no. This action allowsthe user to log on and then forces the user to immediately apply a new password.

Access granted by the /Management/Users object overrides any access restrictionsimposed by “delegated administration” policy ACLs under/Management/Groups/group_name. For information on delegated administration, seeChapter 6, “Delegating administration tasks” on page 79.

/Management/Groups permissionsThis object allows administration users to manage groups and group membership.Action tasks and associated permissions include:

Permission Operation Description

d delete Delete a group.

group delete

m modify Modify group descriptions. Remove one or more usermembers of a group.

group modify descriptiongroup modify remove

N create Create a new group. Import group data from the userregistry.

group creategroup import

v view List groups and show group details.

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

A add Add one or more users to a group.

group modify add

The A permission is required on your entry in the ACL on a group to allow you toadd existing users to your group. Use the user create command (which requires Npermission) to create new users and optionally place them in one or more existinggroups.

The capability of adding existing users to your group is powerful because theowner of a group has control over all user members of the group. If you, as theowner of the group, also have delete (d) permission, you can delete this user fromthe entire secure domain.

/Management/GSO permissionsThe /Management/GSO container object of the protected object space allowsadministrators to perform Global Sign-On (GSO) management tasks (whenappropriate 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)

Object and object space permissionsThese commands allows administration users to manage new objects and objectspaces. 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 suggested starting points forsecuring specific regions of the secure domain.

You can add entries for users, groups, any-other (any-authenticated), andunauthenticated to provide a broader range of control and better meet therequirements of your protected object space.

Note the users and groups in each ACL that contain the control (c) permission.Users and groups with the control permission own the ACL and have the power tomodify the ACL entries.


Default root ACL policyCore entries for the default root ACL, default-root, include:Group iv-admin TcmdbvaBAny-other TUnauthenticated T

The root ACL is very basic—everyone can traverse the object space, but cannotperform any other actions. Typically, you would not need to change this. However,one useful function of the root ACL is to quickly deny access to the entire objectspace for an individual user or group.

Consider the following entry in the root ACL:user john -----------------

The consequence of this entry (no permissions) is that user john cannot eventraverse the root container object. This user cannot gain access at all to theprotected object space — regardless of any permissions granted lower down in thetree.

Default /Management ACL policyCore entries for the Management ACL, default-management, include:Group iv-admin TcmdbsvatNWBGroup ivmgrd-servers TsAny-other Tv

At installation, this ACL is attached to the /Management container object in theobject space.

Default /Replica ACL policyCore entries for the Replica management ACL, default-replica, include:Group iv-admin TcbvaBGroup 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 TcmdbsvaAny-other TvUnauthenticated Tv

Default /GSO ACL policyCore entries for the GSO management ACL, default-gso, include:Group iv-admin TcmdbvaBAny-other TvUnauthenticated Tv

Default /Policy ACL policyCore entries for the Policy management ACL, default-policy, include:Group iv-admin TcmdbvaBAny-other TvUnauthenticated Tv


Chapter 4. Protected object policies

The Tivoli Access Manager authorizations service makes decisions on requests foraccess to protected objects in the secure domain. The decision can be based on twotypes of policies:v Access control list (ACL) policiesv Protected object polices (POP)

The purpose of a POP is to impose additional conditions on the operationpermitted by the ACL policy.

Examples of access conditions can include:v Writing a report record to the auditing servicev Restricting access to a specific time period

This chapter discusses how protected object policies are configured and applied toobjects.

This chapter contains the following sections:v “Protected object policies (POP)” on page 61v “Configuring the POP attributes” on page 63v “Authentication strength POP policy (step-up)” on page 65v “Network-based authentication POP policy” on page 67v “Quality of protection POP policy” on page 69

Protected object policies (POP)ACL policies provide the authorization service with information to make a yes orno answer on a request to access a protected object and perform some operation onthat object.

POP policies contain additional conditions on the request that are passed back tothe resource manager along with the yes ACL policy decision from theauthorizations service. It is the responsibility of the resource manager to enforcethe POP conditions.

The following table lists the available attributes for a Tivoli Access Manager POP:


POP attribute Description pdadmin pop commands

Name Name of the policy. This becomes thepop_name in the pdadmin popcommands.

createdelete

Description Descriptive text for the policy. Thisappears in the pop show command.

modify set description

Warning mode Provides administrators a means to testACL and POP policies.

modify set warning

Audit level Specifies type of auditing: all, none,successful access, denied access, errors.

modify set audit-level




Time-of-day access Day and time restrictions for successfulaccess to the protected object.

modify set tod-access

Extended attributes Specifies supplemental data fields. modify set attributemodify delete attributelist attributeshow attribute

Enforced by Resource Manager (such as WebSEAL)


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

modify set qop

IP endpointauthentication methodpolicy

Specifies authentication requirementsfor access from members of externalnetworks.

modify set ipauth addmodify set ipauth removemodify set ipauth anyotherw

POP notes:v The time-of-day access and the IP endpoint authentication method access place

restrictions on the access to the object.v Audit level and quality of protection inform the authorizations service that extra

services are required when permitting access to the object.v Warning mode provides a way to test ACL and POP policies before they are

made active.

Note: The quality of protection and auditing rules specified by the P, I, and Apermissions in previous versions of Tivoli Access Manager are now specifiedin POP policies.

Creating and deleting protected object policiesProtected object policies (POP) operate in a similar way to ACL policies—youcreate and configure a POP and then attach the POP to objects in the protectedobject space.

POP policies are inherited in the same way as ACL policies. Both POP policies andACL policies are placed in the master authorization database, which is controlledby the policy server.

Create and list a POPpdadmin> pop create pop_name

For example:pdadmin> pop create testpdadmin> pop list test

The new POP contains the following default settings:pdadmin> pop show test

Protected object policy: testDescription:Warning: noAudit level: noneQuality of protection: none


Time of day access: sun, mon, tue, wed, thu, fri, sat:anytime:local

IP Endpoint Authentication Method PolicyAny Other Network 0

Delete a POPpdadmin> 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 marks when you usemore 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 ACL policies.

Attach a POP to an objectThe syntax for attaching a POP 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 is attachedpdadmin> pop find test

/WebSEAL/serverA/index.html

Delete a POPThe syntax for detaching a POP from an object is:pdadmin> pop detach object_name

For example:pdadmin> pop detach /WebSEAL/serverA/index.html

Configuring the POP attributesv Warning mode attributev Audit level attributev Time-of-day attribute

Chapter 4. Protected object policies 63

Warning mode attributeThe purpose of the warning attribute is to allow a security administrator to debugor troubleshoot the accuracy of the authorization policy set on the protected objectspace.

When you set the warning attribute to yes, any action is possible by any user onthe object where the POP is attached. Any access to an object is permitted even ifthe ACL policy attached to the object is set to deny this access.

Audit records are generated that capture the results of all ACL policies withwarning mode set throughout the object space. The audit log shows the outcomeof an authorization decision as it would have been made if the warning attributehas been set to no. Therefore, the administrator can determine if policy is set andenforced correctly.

Syntax:pdadmin> pop modify pop_name set warning {yes|no}

For example:pdadmin> pop modify test set warning yes

Audit level attributeThe POP audit level has the expanded ability to specify a level of auditing. Forexample, if auditing is set to record unsuccessful events, you can use the results todetect an unusual number of failed access attempts on a particular resource.

Auditing records are written in a standard XML format that allows easy parsing toextract whatever information is required. See “Audit trail files” on page 111.

Syntax: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 in successful access.

deny Audit all requests on a protected object that result in denial of access.

error Audit all internally generated error messages resulting from a denial ofaccess to the protected object.

You can apply any combination of these three values. Use a comma as a separatorcharacter 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 specific day and timeconditions on the access to a protected object. This type of condition might beuseful to limit access to information that regularly requires periods of inactivity formodification and updates.


There is an ACL policy permission (B) that overrides the time-of-day conditions onan object. This permission should be used only by a high-level administrator whoneeds full access to the protected 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 a time-range and usesthe 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 hour time) as:hhmm-hhmm

For example:0700-1945

The optional time zone for the server (not the client) is local by default.

For example:pdadmin> pop modify test set tod-access mon,tue,fri:1315-1730

Authentication strength POP policy (step-up)You can use protected object policies (POP) to enforce certain access conditions onspecific resources. The authentication strength POP policy makes it possible tocontrol access to objects based on authentication method.

You can use this functionality, sometimes known as step-up authentication, toensure that users accessing more sensitive resources use a stronger authenticationmechanism. You might want this condition because of the greater threat ofimproper access to certain resources.

For example, you can provide greater security to a junctioned region of theprotected object space by applying a step-up POP policy that requires a strongerlevel of authentication than the client used when initially entering the securedomain.

Authentication strength policy is set in the IP endpoint authentication methodattribute of a POP policy.

Configuring levels for step-up authenticationThe first step in configuring authentication-specific access is to configure thesupported authentication methods and determine the order in which theseauthentication methods should be considered stronger.

Any client accessing a resource manager has an authentication level, such as“unauthenticated” or “password”, which indicates the method by which the clientlast authenticated with the resource manager.

In some situations, it might be necessary to enforce minimum safe levels ofauthentication required to access certain resources. For example, in one


environment, authentication by token passcode might be considered more securethan authentication by username and password. Another environment mightrequire different standards.

Rather than forcing clients to restart their sessions with the resource manager whenthey do not meet the required level of authentication, the step-up authenticationmechanism provides clients a second chance to reauthenticate using the requiredmethod (level).

Step-up authentication allows resource managers to control the method in whichusers access a protected resource. If step-up authentication is required because theuser has not authenticated with the sufficient method, then the access decision isstill permitted by the authorization engine but the resource manager is presentedwith a required authentication level as an output of the authorization decision. Theresource manager can then decide how to further authenticate the user so as togain the required level of authentication needed for the user to access the object.

How a particular authentication method is mapped to an authentication level isentirely determined by the resource manager application. For all cases, the absoluteminimum acceptable method of authentication should be set as level 0 with moresecure methods being mapped to integral numbers in ascending order (1..x) fromthere.

Applying step-up authentication policyStep-up authentication is implemented through a POP policy placed on the objectsrequiring authentication-sensitive authorization. You use the IP endpointauthentication method attribute of a POP policy.

The pdadmin pop modify set ipauth command specifies both the allowednetworks and the required authentication level in the IP endpoint authenticationmethod attribute.

The configured authentication levels can be linked to IP address ranges. Thismethod is intended to provide management flexibility. If filtering users by IPaddress is not important, you can set a single entry for anyothernw (any othernetwork). This setting affects all accessing users, regardless of IP address, andrequire them to authenticate at the specified level. This is the most commonmethod for implementing step-up authentication.

Syntax:pdadmin> pop modify pop-name set ipauth anyothernw level-index

The anyothernw entry is used as a network range that matches any network nototherwise specified in the POP. This method used to create a default entry whichcould either deny all unmatched IP addresses or allow anyone access who canmeet the authentication level requirement.

By default, anyothernw appears in a POP with an authentication level index of 0.The entry appears as Any Other Network in the pop show command:pdadmin> pop show test

Protected object policy: testDescription: Test POPWarning: noAudit level: noneQuality of protection: none


Time of day access: sun, mon, tue, wed, thu, fri, sat:anytime:local

IP Endpoint Authentication Method PolicyAny Other Network0

Distinguishing step-up from multi-factor authenticationTivoli Access Manager step-up authentication and multi-factor authentication aretwo different and distinct mechanisms for controlling access to resources. TivoliAccess Manager only provides step-up authentication functionality, as described inthis chapter.

Multi-factor authentication forces a user to authenticate using two or more levelsof authentication. For example, the access control on a protected resource canrequire that the user authenticate with both user name/password and username/token passcode.

Tivoli Access Manager step-up authentication relies on a preconfigured hierarchyof authentication levels and enforces a specific level of authentication according tothe policy set on a resource. Step-up authentication does not force the user toauthenticate using multiple levels of authentication to access any given resource.Instead, step-up authentication requires the user to authenticate at a level at leastas high as that required by the policy protecting the resource.

A step-up authentication example is as shown:

The following are configured authentication levels:v authentication level 1 = user name/passwordv authentication level 2 = user name/token passcode

The following object is protected by a POP requiring authentication level 1:/WebSEAL/hostA/junction

The following object is protected by a POP requiring authentication level 2:/WebSEAL/hostA/junction/applicationA

Under step-up authentication, user name/password (level 1) authentication isrequired to access /WebSEAL/hostA/junction.

However, user name/token passcode (level 2) authentication is required to access/WebSEAL/hostA/junction/applicationA. If the user is currently logged in with auser name and password, a prompt appears requesting user name and tokenpasscode information (the step-up). However, if the user initially logs in toWebSEAL with user name and token passcode, access to applicationA isimmediate (assuming a positive ACL check).

Multi-factor authentication would require both level 1 and level 2 authenticationfor access to applicationA.

Network-based authentication POP policyThe network-based authentication POP policy makes it possible to control access toobjects based on the IP address of the user. You can use this functionality toprevent specific IP addresses (or IP address ranges) from accessing any resources inyour secure domain.


You can also apply step-up authentication configuration to this policy and requirea specific authentication method for each specified IP address range.

Network-based authentication policy is set in the IP endpoint authenticationmethod attribute of a POP policy. You must specify two requirements in thisattribute:v Authentication levels

For more information on authentication levels, see “Authentication strength POPpolicy (step-up)” on page 65.

v Allowed networks

Specifying IP addresses and rangesNow you must specify the IP addresses and IP address ranges permitted by thisPOP policy.

The pdadmin pop modify set ipauth add command specifies both the network (ornetwork range) and the required authentication level in the IP endpointauthentication method attribute.

Syntax:pdadmin> pop modify pop-name set ipauth add network netmask level-index

The configured authentication levels are linked to IP address ranges. This methodis intended to provide flexibility. If filtering users by IP address is not important,you can set a single entry for anyothernw (any other network). This setting affectsall accessing users, regardless of IP address, and require them to authenticate at thespecified level.

Syntax:pdadmin> pop modify pop-name set ipauth anyothernw level-index

Conversely, if you want to ignore the authentication level and want to allow ordeny access based only on IP address, you can use level 0 for ranges that you wantto allow in and forbidden for ranges you want to deny.

The anyothernw entry is used as a network range that matches any network nototherwise specified in the POP. This method is used to create a default entry thatcould either deny all unmatched IP addresses or allow access to anyone who meetsthe authentication level requirement.

By default, anyothernw appears in a POP with an authentication level index of 0.The entry appears as Any Other Network in the pop show command: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 Network0

ExamplesRequire users from IP address range 9.0.0.0 and netmask 255.0.0.0 to use level 1authentication (“password” by default):


pdadmin> pop modify test set ipauth add 9.0.0.0 255.0.0.0 1

Require a specific user to use level 0 authentication:pdadmin> pop modify test set ipauth add 9.1.2.3 255.255.255.255 0

Prevent all users (other than those specified as in the examples above) fromaccessing the object:pdadmin> pop modify test set ipauth anyothernw forbidden

Disabling step-up authentication by IP addressSyntax:pdadmin> pop modify pop-name set ipauth remove network netmask

For example:pdadmin> pop modify test set ipauth remove 9.0.0.0 255.0.0.0

Network-based authentication algorithmThe authorization engine uses the following algorithm to process the conditions ina POP:1. Check the IP endpoint authentication method policy on the POP.2. Check ACL permissions.3. Check time-of-day policy on the POP.4. Check the audit level policy on the POP.

Network-based authentication notes and limitationsThe IP address used by the resource manager for enforcing the network-basedauthentication policy should be the IP address of the originator of the connection.If your network topology uses proxies, the address that appears to the resourcemanager might be the IP address of the proxy server.

In this case, the resource manager is not able to definitively identify the true clientIP address. You must be careful when setting a network-based authenticationpolicy that network clients can directly connect to the resource manager.

Quality of protection POP policyThe quality of protection POP attribute allows you to specify what level of dataprotection is required when performing an operation on an object.

The quality of protection POP attribute permits a single transaction where the yesresponse to the ACL decision also includes the required quality of protection level.If the resource manager cannot guarantee the required level of protection, therequest is denied.

Syntax:pdadmin> pop modify pop-name set qop {none|integrity|privacy}

QOP level Description

Privacy Data encryption is required (SSL).

Integrity Use some mechanism to ensure that the data has not changed.


For example:pdadmin> pop modify test set qop privacy


Chapter 5. Using Web Portal Manager

The Web Portal Manager is a Web-based interface used to manage security policyfor the secure domain. The Web Portal Manager provides management andadministration of users, groups, roles, permissions, policies, and application accessprovisioning. The tasks that can be completed using the Web Portal Manager aredocumented in the online help system. Use the help system as your first point ofreference when looking for Web Portal Manager task-based information. Thefeatures outlined in this chapter include delegate administration and Web PortalManager functionality.

Note: Prior to starting Web Portal Manager, ensure the IBM WebSphereApplication Server is running.

This chapter contains the following sections:v “Delegating administration using Web Portal Manager”v “Personalizing the interface” on page 75v “Functionality of Web Portal Manager” on page 75

Delegating administration using Web Portal ManagerOne of the most powerful features of the Web Portal Manager is a rich set ofdelegated management services that enables a business to delegate useradministration, group and role administration, security administration, andapplication access provisioning to participants (subdomains) in the businesssystem. These subdomains can further delegate management and administration totrusted subdomains under their control; thereby, supporting multi-level delegationand management hierarchy based on roles.

Delegate administration using Web Portal Manager provides a Tivoli AccessManager administrator the capability to create delegate user domains, create newusers, add existing users to additional domains, and assign various types ofadministrators to the domains. These delegate administrators can then perform asubset of administration functions, depending on their type, on the users in theirassigned domain. This concept of delegate user administration can be applied to allTivoli Access Manager users so that a hierarchy of user domains is formed. In thishierarchical arrangement, each Tivoli Access Manager user can be managed onlyby the administrators for the domain of which the user is member or by theadministrators for the super domains (explained later in this chapter). The actualfunctions that administrators can perform depend on their assigned administratortype.

A Tivoli Access Manager administrator, such as sec_master, can create a number ofenterprise domains and assign one or multiple types of administrators to eachenterprise domain. The administrator for an enterprise domain can create newusers in the domain and add existing Tivoli Access Manager users to the domain.

In addition to this user-related function, Tivoli Access Manager administrators cancreate new domains below the enterprise domain level (subdomains) and assignusers to be the administrators for these new domains (domain administrators).Administrators of the new domains can then create new users in their owndomain.


The Tivoli Access Manager administrator for the enterprise domain (the domain’ssuperdomain) also has authority to administer the domain. Tivoli Access Manageradministrators can create and manage as many domains under their authority asnecessary to fulfill their unique business needs.

Note: An enterprise domain is basically the top-level domain, and any domaincreated below an enterprise domain level is just called a domain.

As an example of this type of multiple domain administration in Figure 23, a TivoliAccess Manager administrator can create enterprise domains A and B and assignan administrator for each domain. The domain administrator for enterprise domainB can create new users P, Q. A Tivoli Access Manager administrator can createdomains C and D below the enterprise domains A and B, and assign domainadministrators to C and D. The Tivoli Access Manager administrator can thencreate domain E below domain D, and assign a domain administrator to E. Thedomain administrator for domain E can then create new users X, Y, and Z withindomain E. Because a domain administrator for a domain can also administer thatdomain’s subdomains, both the domain administrators for domain D and thedomain administrator for enterprise domain B can create users (or perform otheradministrative functions) for domain E.

For each delegate user domain (including the enterprise domain), predefinedadministrator types can be assigned in that domain. The following are the variousadministrator types and the set of administrative functions that can be performedby administrators assigned to each of these types:v Tivoli Access Manager Administrator. The Tivoli Access Manager administrator

is a member of the iv-admin group. The Tivoli Access Manager administratorcan perform all delegate administration functions.

v Domain Administrator. The domain administrator can perform administrativefunctions for the users in their domain. Domain administrators can create new

Secure Domain

Enterprise Domain A Enterprise Domain B …(Users P, Q, ...)

Domain C Domain D

Domain E(Users X, Y, Z, ...)

…

Figure 23. Delegate administrators


users and administrators in their own domain, and assign an existing domainuser to be an administrator (of any type except domain administrator) for thedomain.

v Senior Administrator. A senior administrator has the same authority as adomain administrator, except that a senior administrator cannot assignadditional administrators.

v Administrator. An administrator has the same authority as a senioradministrator, except that an administrator cannot create new domain users. Anadministrator can modify an existing user’s properties.

v Support Administrator. A support administrator serves the user in a helpdeskrole and is able to view users’ properties, change users’ passwords, and modifythe Is Password Valid? flags for users.

The delegate user administration tool enforces the administrative functions that canbe performed with each administrator type. When an administrator logs in,administrative functions become available in accordance with that user’sadministrator type.

Accessing the delegate administration functionsThe delegate administration functions are accessed from a different URL than thebase pdadmin functions. The base pdadmin functions do not include the delegateadministration functions. The delegate administration functions are considered tobe a separate application.

To access the delegate administration functions, go to:

https://hostname/delegate

To access the base pdadmin functions, go to:

https://hostname/pdadmin

Delegating role administrationAnother part of the delegate administration system of the Web Portal Manager isrole administration. To successfully deploy Tivoli Access Manager, a security policymust be defined that regulates access to objects, and the actions that can beperformed on those objects. Execution of this policy is usually difficult because thesecurity policy is often defined by high-level members of an organization with anemphasis on global security issues. The policy then must be put into action bylocal members of the organization, who see the lower-level details andimplementation concerns. Often these two groups have similar goals for overallorganizational security, but interconnecting these two disparate points of view ischallenging. Role-based administration provides an enhanced ability fororganizational security to meet the requirements of today’s complex securityrequirements for scalability, simplicity, and flexibility.

To understand role administration, the first concept that must be defined is a role.A role consists of a number of tasks, responsibilities, or skills required to fulfill aspecific job requirement. When this definition is contrasted against the accesscontrol list (ACL) model of Tivoli Access Manager, a role becomes a list of one ormore pairs of objects and one or more access permissions that are applied to theobject. For example:v object 1: permission 1v object 2: permission 2, 3, and 4

Chapter 5. Using Web Portal Manager 73

v object 3: permission 5

In order for a role to be used it must be activated. A role is activated when anTivoli Access Manager administrator enables its definition in the Tivoli AccessManager namespace. After a role is activated and a user is assigned to the role, theuser has permission 1 for object 1, permission 2, 3, and 4 for object 2, andpermission 5 for object 3. The access permissions for these objects allow the user toaccess the objects, and therefore perform the job responsibility defined by the role.For example, an accountant role can be defined to consist of the following twopairs of objects and permissions:v payroll check object: create/modify/deletev reimbursement request object: approve

When this role is activated and an employee in the accounting department isassigned to this role, that employee is able to create, modify, or delete a payrollcheck and approve a reimbursement request; thus, performing the job that anaccountant is expected to perform.

To successfully administer roles, an administrator must be able to perform threetypes of tasks:v Role creationv Role assignmentv Role activation

Role creation involves defining a role so that it has a list of one or more pairs ofTivoli Access Manager objects and permissions that can be applied to the objects.When a role is created in Web Portal Manager, a Tivoli Access Manager group iscreated to represent the role. A corresponding group object in the managementobject space is also created. The object/permissions pair information for the role isstored in the extended attributes associated with the group object. Only a TivoliAccess Manager administrator is able to create a role.

Role assignment consists of assigning a user to a role that has already been created.The purpose behind assigning users to roles is to let those users have the accesspermissions on the objects defined in the role. This function reduces the workloadinvolved in maintaining user-permission-object relationships, because roleassignment is separated from object/access permission management. When a useris assigned to a role in Web Portal Manager, the user is added as a member of thegroup that represents the role. Domain administrators, senior administrators, andadministrators of a domain can assign users in their domains to a role.

Role activation enables a newly created role to function. After a role is created and auser is assigned to that role, the user does not have access permissions for theobjects defined in the role until the role is activated. When a role is activated inWeb Portal Manager, an ACL entry that contains the group that represents the roleand the access permissions defined in the role are added to the ACL for each objectdefined in the role. Because a user has been added to the group when the user isassigned to the role, that user has permissions to access the objects only after a roleis activated. Only a Tivoli Access Manager administrator is able to activate a role.

A role is an entity that can be delegated and administered. When a role is created,it can be assigned to an enterprise domain. Domain administrators can in turnassign any of the roles within that domain to any subdomain. When a role isassigned to a subdomain, an administrator for that subdomain can assign anysubdomain users to that role. This process of assigning roles to subdomains can be


repeated as needed so that roles can be made available to the appropriate users.Role assignment to an enterprise domain can be performed only by the TivoliAccess Manager administrator. Domain administrators can assign a role to theirsubdomains.

Personalizing the interfaceThe Web Portal Manager allows for customization of the interface for a TivoliAccess Manager user. A Tivoli Access Manager user can rebrand the Web PortalManager by modifying the configuration to specify which HTML page or GIF fileshould be loaded when the Web Portal Manager starts up. There are four areasthat can be customized in the Web Portal Manager by changing the options in thepdwpm.conf configuration file:1. loginGif — This shows the image on the login page.2. splashGif — This shows the image on the welcome page, after the login page.3. infoBarGif — This shows the IBM image on the bottom right of the page.4. bannerFile — This shows the banner at the top of each page.

To customize the images, do the following:1. Change the value of the options to specify different images.2. Place the new images in the one of the following directories:

v For UNIX systems:websphere_install_dir/WebSphere/AppServer/installedApps/pdwpm.ear/pdwpm.war/images

v For Windows systems:websphere_install_dir\WebSphere\AppServer\installedApps\pdwpm.ear\pdwpm.war\images

3. For locale-specific versions of the images, create subdirectories under thefollowing directories for each of the locales and place the new images in thesubdirectories:v For UNIX systems:

websphere_install_dir/WebSphere/AppServer/installedApps/pdwpm.ear/pdwpm.war/images/locale/myImage.gif

v For Windows systems:websphere_install_dir\WebSphere\AppServer\installedApps\pdwpm.ear\pdwpm.war\images\locale\myImage.gif

To create a customized top banner for the Web Portal Manager, do the following:1. Create a JSP or HTML file.2. Put the JSP or HTML file you created in the same directory as the

top_banner.jsp file.3. Change the value of the bannerFile option, whose default value is

bannerFile=top_banner.jsp, to point to the new JSP or HTML filename.

The layout of the frame is set up by the pdmainframe.jsp file, which sets the framefor the page to be a height of 50 pixels.

Functionality of Web Portal ManagerWeb Portal Manager deployments can grow to support large number of users. Asthe number of users grows, so does the number of administrators required tomanage these users. Self-registration and self-care are features of the Web PortalManager that can be used to reduce the administration load. Included with the


Web Portal Manager is a sample code that implements a self-registration page. Thesample code shows how to use the Tivoli Access Manager Java AdministrationAPIs along with Java 2 Platform, Enterprise Edition (J2EE) servlets and Java ServerPages (JSPs) to implement self-registration. The Web Portal Manager also supportsself-care operations by allowing Tivoli Access Manager users to change their TivoliAccess Manager password through the Web Portal Manager.

Self-registration sampleThe Web Portal Manager includes a sample application that allows end-users toperform self-registration. Self-registration is the process by which a user can enterrequired data to become a registered Tivoli Access Manager user, without theinvolvement of an administrator. One possible scenario for implementingself-registration is where users open a Web browser to view a self-registration Webpage. On this Web page, the user enters specific identification information (eithercompany-specific or user-specific) with a Tivoli Access Manager user ID andpassword. The identification information provided by the user is then validatedand the user is created in the Tivoli Access Manager registry.

Tivoli Access Manager provides a self-registration sample to demonstrate how itworks. Note that this sample is supported only on an LDAP registry, not Dominoor Active Directory.

Process of the self-registration sampleBecause users do not usually have permission to create objects in Tivoli AccessManager, the self-registration sample requires the ID and password of anadministrator who has permission to create users. This login information is thenused to create users when somebody enters the required information on theregistration page.

The following information is requested the first time the self-registration sample isaccessed. This data is saved by the servlet in memory and then used to createusers who request to be registered.v Administrator namev Passwordv Registry container

The administrator name and password should be the name of an administratorwho has permission to create users in Tivoli Access Manager. The sec_masteradministrator has the proper access by default. The Registry Container field shouldbe the base name in LDAP where user entries should go. This value is used toconstruct the distinguished name (DN) of self-registered users.

For example, enter o=ibm,c=us and the registered users are created in LDAP as,cn=FirstnameLastname,o=ibm,c=us. The user is not added to any groups. In a realapplication, the user would probably be added to some groups to have access tosome applications. After the administrator information is entered, this page is notshown again. If you access the sample, you are shown only the registration pagewhere you can enter the first name, last name, and a password.

Note that the administrator login is saved in the servlet session. Any user whoaccesses the self-registration sample from the same browser can create a user inTivoli Access Manager. You must restart the application server to clear theadministrator login information.


For this sample, the ID and password are not saved in a secure manner. If you usethis sample as the basis for a production registration application, you shouldconsider ways to secure the administrator login information.

Java server pages in the self-registration sampleThere are three JSP pages in the sample application:v regAdmin.jsp is the page shown to gather the administrator login information.v regProp.jsp is the page shown to gather user first name, last name, and

password.v regControl.jsp contains the code that creates the user. This page receives and

processes the registration requests. This could also be a servlet class.

The files are installed in the following directory:WASdir/installedApplications/pdwpm.ear/pdwpm_sampleReg.war/register

where WASdir is the directory where WebSphere is installed.

When the administrator login information is entered, a JRTE PDContext is createdand stored in the user servlet session as shown in the following:String adminid = request.getParameter("admin");String adminPassword = request.getParameter("password");String ldapSuffix = request.getParameter("suffix");

...// Try a login

try {ctx = new PDContext(adminid,

adminPassword.toCharArray(),url);

// Save the PDcontext and the LDAP Suffixsession.setAttribute("regAdminCtx", ctx);session.setAttribute("ldapSuffix", ldapSuffix);

} catch(PDException e) {// process exception...

}

After the user enters the new user information, the PDContext is retrieved from thesession and used to create the new user as shown in the following:// Creating the PD User

pwd = request.getParameter("password");ldapcn = request.getParameter("ldapcn");ldapsn = request.getParameter("ldapsn");ldapdn = "cn=" + ldapcn + ldapsn + "," + ldapSuffix;userid = ldapcn + ldapsn;desc = ldapcn + " " + ldapsn;

ctx = (PDContext)session.getAttribute("regAdminCtx");

// Make sure the session has not timed outif ( ctx == null ) {

%><%@ include file="regAdmin.jsp" %>

<% return;}

PDMessages messages = new PDMessages();try {

createUser(bundle, ctx, userid, pwd, desc, ldapcn,ldapsn, ldapdn, usergroups, acc_valid,pwd_valid, gso_user, no_pwd_pol,messages);


succmsg = userid +ResourceFile.getString(bundle,

"userRegisteredMsg");

} catch(PDException e) {// process exception...

}

The new user’s ID is the first name and last name concatenated together.

Accessing the self-registration sampleThe self-registration sample can be accessed from the following URL:https://hostname/register

where hostname is the machine where IBM HTTP Server and WebSphere arerunning.

Self-care using Web Portal ManagerWeb Portal Manager supports self-care. Users are able to go to the Web PortalManager delegate administration page and manage their passwords. Use thefollowing URL to get to the delegate administration page:https://hostname/delegate

where hostname is the machine where IBM HTTP Server and WebSphere arerunning.

After logging in, the user should go to the Change My Password task.


Chapter 6. Delegating administration tasks

Tivoli Access Manager allows high-level administrators to delegate responsibilitiesfor managing the secure domain to lower-level administrators. This capability isvital to successfully managing very large domains composed of numerousdepartments.

Tivoli Access Manager supports delegated administration in the following areas:v Delegated management of resources in subregions of the object space

Administration capabilities are restricted to a portion of the object space.v Delegated management of groups and users

Administration capabilities are restricted to a portion of the user population.

This chapter contains the following sections:v “Delegating object space management”v “Delegating group management” on page 81v “Managing delegated administration policy” on page 86

Delegating object space managementThe distribution of administration responsibilities within a secure domain is calledmanagement delegation. The need for management delegation generally arisesfrom the growing demands of a large site containing many distinct departmentalor resource divisions.

Typically, a large object space can be organized into regions representing thesedepartments or divisions. Each distinct region of the domain is usually betterorganized and maintained by a manager who is more familiar with the issues andneeds of that branch.

In a secure domain, the sec_master account in the user registry is initially the onlyaccount with administration permission. As sec_master, you can createmanagement accounts and assign to these accounts appropriate controls for specificregions of the object space.

Structuring the object space for management delegationStructure your object space to contain distinct regions, or branches, wheresubmanagement responsibilities—specific to that branch—can be carried out.

In the example below, both the Engineering and Publications regions of the objectspace require separate management control. Control of these regions begins withthe root of each region and extends to all objects below.


Default administration users and groupsTivoli Access Manager provides several important administration groups duringinstallation. For information on these user and groups, see “Default administrationusers and groups” on page 28.

Example: Management delegationA large object space might require many administration users to manage a varietyof subbranches. In this scenario, the ACLs for the directories on the path to each ofthese branches must contain entries for each account, with traverse permission. Fora site with many administration users, these ACLs could contain a long list ofentries representing all these administration accounts.

The following technique resolves the problem of numerous ACL entries foradministrators: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 directories leading to

each subbranch that requires management delegation.4. At each branch root ACL, add the appropriate administration user entry (with

b, c, T, plus other appropriate permissions).5. The administrator can now remove the administration group ACL entry (and

any other entry) from the root.Now only that user has control over the root and all objects below.

In the example below, the group iv-admin contains all administration users. Userpub-manager is a member of this group and therefore, has the necessary traversepermission required to navigate to the Publications directory.

The Publications directory includes the user pub-manager entry in its ACL.Because pub-manager is the delegated administrator of this branch (with theappropriate permissions), pub-manager can remove the iv-admin group account(and any other ACL entries) from the Publications ACL to gain total control overthat branch of the Web space.

Object Space

/WebSEAL

Engineering Server

Publications

Marketing Server

Resources

Figure 24. Structuring the object space for management delegation


Delegating group managementIn order to manage a large or complex set of users, you can delegate themanagement of specific groups of users to lower-level administrators. When anadministrator is given policy management control of a group, that administratorhas policy management control over the user members of that group.

Delegated group management defines:v Who has administration responsibility for a specific group (and the user

members of that group)v The level of group and user control given to this administrator

In this discussion, the term, administrator, refers to the responsibilities and controlsgranted to an otherwise typical user. An administrator of delegated duties is anormal user with additional powers to perform certain management tasks.

Setting up delegated group management requires the following steps:1. Determine a logical and practical hierarchy of the users and user types 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 the administrator-user entry.5. Assign, to this administrator-user entry, the specific permissions needed to

perform the required tasks.

/WebSEALserver

/Resources

/Marketing

group iv-admin bT...user pub-manager abcTdmlrx

/Publications

user sec_master abcTdmlrxgroup iv-admin bT

user sec_master abcTdmlrxgroup iv-admin bT

= explicit ACL

= inherited ACL

Figure 25. Management Delegation Example

Chapter 6. Delegating administration tasks 81

Creating group container objectsBy default, the /Management region of the Tivoli Access Manager object space has aGroups container object that you can use to organize the hierarchy of groups inyour secure domain.

Container objects are structural designations that allow you to organize the objectspace into distinct and hierarchical functional regions. Group container objectsallow you to define distinct categories of group types. You create actual groupswithin each specific group container object.

Use the pdadmin object create command to create a new group container object:pdadmin> object create obj-name description type ispolicyattachable {yes|no}


obj-name Full path and name of the new group container object. Path mustbegin with /Management/Groups.

description Any text string describing the object. This information appears inthe object show command.

type The type argument identifies the specific graphical iconassociated with this object and displayed by the Web PortalManager. Types range from 0-17 (see table below). Type 14 isrequired for delegated administration.

ispolicyattachable Determines whether you can attach an ACL policy to this object.

Object types

0 – unknown1 – secure domain2 – file3 – executable program4 – directory5 – junction6 – WebSEAL server7 – unused8 – unused9 – HTTP server

10 – non-existent object11 – container object12 – leaf object13 – port14 – application container object

(required for delegated administration)15 – application leaf object16 – management object17 – unused

For example:pdadmin> object create /Management/Groups/Travel “TravelContainer Object” 14 ispolicyattachable yes

–

–

+

/Management

/Management/Groups

/Management/Groups/Travel

Figure 26. Group container object


For example, you can also use the pdadmin group create command to create agroup container object. See “Creating groups”.

Creating groupsUse the pdadmin group create command to create a new group and optionallyplace this group in a group container object. If the container object does notcurrently 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 object where this newgroup should be located. If no group container object is specified, thegroup is placed under /Management/Groups.

v All new group container objects that you create appear under the default/Management/Groups container. To create a container at another sublevel, use arelative path name for the group_container variable.

v The group create command does not allow you to create a group containerobject without a group.

v To add a new group to the object space, the administrator must have createpermission (N) on the ACL governing the associated group container object.If no group container object is specified, the administrator ACL entry (with thecreate permission) must be specified in the ACL governing the/Management/Groups container.At installation, a single default ACL (default-management)—attached to/Management—defines the permissions on all groups and group containers. Youmust add appropriate explicit ACLs to customize this control.

v You can add multiple groups to a single group container.The ACL on the group container object controls (through inheritance) all groupslocated under the container object. The container object and its groups are nowthe domain of the administrator with the delegated responsibilities.

v The placement of a new group in the object space is fixed on creation.As soon as a group is created, you can move its position only by deleting thegroup from the object space (but not LDAP) and then importing the group to anew location (users in the group are 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 an appropriateACL to the group object or group container object.

The ACL, constructed and attached by a higher-level administrator, should containthe appropriate permissions for the actions that must be performed by thedelegated administrator of that group (or groups).

If the group is located under the /Management/Groups section of the object space,the ACL must be attached to /Management/Groups or the group itself.

If the group is located under a group container object, the ACL must be attached tothe group container object or the group itself. If you attach the ACL to the/Management/Groups container object, the ACL would impact all other groupcontainer objects located below in the object space.

The ACL that is attached to one of these locations (or inherited from above)determines:v Who controls the group object and the users in the groupv What actions can be performed on the group and its users

For example, in Figure 27, an ACL on /Management/Groups/Travel definespermissions to control both group1 and group2.

The following operations and ACL permissions are appropriate for groupmanagement:

Operation Permission

create (a new group) import (group data from the user 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 the Web PortalManager, to perform these operations.

–

–

–

/Management

/Management/Groups

/Management/Groups/Travel

+ /Management/Groups/Travel/group1

+ /Management/Groups/Travel/group2

Figure 27. Creating new groups under a specific group container


AttentionThe add (A) permission is powerful because it allows you to add any existinguser to your groups. If an outside user is placed into a group, theadministrator of that group now has control of that user (and might sharecontrol of the user with administrators of other groups where that user is amember). This permission is best granted only to high-level administratorswho are responsible for user and group organization and corporate policy.

Because of its power, use caution when assigning an administrator with the Apermission. A delegated administrator with the A permission should not havem, W, N, or d permissions.

Notes:v The create (N) permission must be located in an ACL that is attached to

/Management/Groups or on a group container object.v All other permissions listed can be located in an ACL attached to

/Management/Groups, a group container object, or the group object itself.

ACL policies affecting user managementThe group administrator can perform an action on a user if they have theappropriate permission defined on any of the groups where that user is a member.

The following operations and ACL permissions are appropriate for usermanagement:

Operation Permission

create (a new user within one or more specifiedgroups) 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 the Web PortalManager, to perform these operations.

Notes:v The create (N) permission (in the group ACL or group container ACL) allows

you to create or import a user and enter that user into the groups you control.user create user1 “cn=user1,c=us” user1 user1 adcde group1user import user2 “cn=user2,c=us” group1

v You can also create a user without designating a group. In this case, however,the create (N) permission must be located in an ACL on the /Management/Userscontainer object.The ACL attached to /Management/Users defines the permissions for all users(whether they are members of a group or not).


v A group administrator can perform an operation on a user if that administratorhas the appropriate permission defined in any group where that user is amember.

v If a user is not a member of any group, an administrator must have appropriatepermissions in an ACL on /Management/Users to perform operations on thatuser.

v The password (W) permission is appropriate for helpdesk operators who mustassist users who have lost their passwords.The operator can reset the lost password to some known value, and then setuser modify password-valid (pdadmin) to no. This action would force the userto change the password at the next login.

v The view (v) permission is used to control the output of user list, user list-dn,user show groups, group list, and group list-dn commands. The viewpermission is used to filter the output of these commands. If the user does nothave view permission on a group or user that is being returned by thecommand, that group or user is filtered from the output.

Managing delegated administration policyThe previous two sections described separately how to delegate administration ofsecurity policy for protecting resources in your secure domain and also how todelegate management of the users who access those resources. These twoindividual aspects of delegated administration often need to be combined toestablish a complete delegated administration security policy.

Great care, however, must be taken when doing this. In particular, you must becareful which permissions you grant in combination with each other.

For example, the A permission should never be granted together with the m, W, ord permissions except to the most powerful and trusted administrators (and maybenot at all). The consequence of granting both A and W to administrators is that theadministrators can add any user to the group for which they have thesepermissions and then change that user’s password. Any user can be chosen,including a more senior administrator or even sec_master. In this way, a maliciousadministrator could gain full access to the system by logging on as that senior user.

The consequence of granting the A and m permissions together are similar exceptthat an administrator with both of these permissions needs only this combinationto disable any account in the group. The consequence of granting the A and dpermissions together are similar except that an administrator with both of thesepermissions needs only this combination to delete any user ID in the group.

When defining a complete delegated administration policy, these constraints implya certain structure and use to your user groups.

You must establish groups that you use to delegate user management tasks—suchas creating new users, deleting users and resetting users’ passwords.Administrators that perform user administration tasks should have the N, d, m, W,and v permissions to create, delete, modify (disable or change description), reset orinvalidate passwords, and view users they are responsible for managing. Thesegroups are used only for delegating user management and should not be used forprotecting other resources in the secure domain.

You must also establish groups that you use to delegate management of securitypolicy for protected resources within the secure domain. Administrators controlling


security policy for these groups should have the A and v permissions but none ofthe 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 with resources thatshould be:v publicly accessiblev accessible only to customers and employeesv accessible only to employees

The space can be structured as:/WebSEAL/

www.company_xyz.com/customers/sales/

An ACL at the root of the www.company_xyz.com Web space allows public accessto everything in the Web space. An ACL at customers allows access to customersand sales people and another ACL at sales allows access only to sales people.These ACLs might look like:public-access

user sec_master abcTdmlrxany-other Tlrxunauthenticated Tlrx

customer-accessuser sec_master abcTdmlrxgroup customers Tlrxgroup sales Tlrxany-otherunauthenticated

sales-accessuser sec_master abcTdmlrxgroup sales Tlrxany-otherunauthenticated

These ACLs would be attached respectively at:/WebSEAL/www.company_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 create new accounts for customersand grant them access to the customers portion of the Web space. Onlyadministrators (members of the sales-admin group) are allowed to manageaccounts for new sales people.

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 sales group, whichin turn, is used to control access to the sales-people-only portion of the Web space.


The only permission required is for the sales-admin group to be able to add andremove users from this group. The view (v) permission is also useful toadministrators to allow them to view the group membership and the users in thegroup.sales-admin

group super-admin Tabcgroup admin TAv

The sales-users-admin ACL, by attachment to the sales-users group, controls whocan manage users who are members of the sales-users group (this is thesales-admin group again).sales-users-admin

group super-admin Tabcgroup admin TNWdmv

Similarly, the customers-admin ACL is used to administer membership of thecustomers group, which in turn, is used to control access to the customers-onlyportion of the Web space.customers-admin

group super-admin Tabcgroup sales TAv

The customers-users-admin ACL, by attachment to the customers-users group,controls who can manage the members of the customers-users group (this the salesgroup again). We also allow members of the sales-admin group to managecustomers.customers-users-admin

group super-admin Tabcgroup sales TNWdmvgroup admin TNWdmv

Notice in each ACL, a super-admin group entry is granted attach, browse, andcontrol permission. Members of the super-admin group are responsible foradministering these ACLs.


Chapter 7. Managing Tivoli Access Manager servers

This chapter provides detailed information for performing general administrationand configuration tasks on the Tivoli Access Manager servers. The configurationfiles that support each server are also discussed.

This chapter contains the following sections:v “Tivoli Access Manager servers” on page 89v “Tivoli Access Manager utilities” on page 91v “Starting and stopping Tivoli Access Manager servers” on page 92v “Automating server startup at boot time” on page 94v “Policy server administration” on page 94

Tivoli Access Manager serversTivoli Access Manager consists of the following server processes (daemons):v policy server (pdmgrd)v authorization server (pdacld)

The policy server (pdmgrd) manages the master authorization (ACL) database andmaintains location information about other Tivoli Access Manager servers in asecure domain. The policy server typically requires very little administration orconfiguration.

The authorization server (pdacld) allows third-party applications to makeauthorization calls (using the authorization API) to the Tivoli Access Managersecurity service. The authorization server also acts as a logging and auditingcollection server to store records of server activity. Typically the authorizationserver requires very little administration or configuration.

Server dependenciesImportant Tivoli Access Manager server dependencies include the following:v There can be only one instance of the policy server and the master authorization

(ACL) database in any secure domain.v The policy server provides authorization database replication services to all

other Tivoli Access Manager servers in the secure domain running in local cachemode.

v Each resource manager (for example, WebSEAL and the authorization server)applies access control policy based on information from the replicatedauthorization database.


Server configuration filesYou can use the server configuration files to customize the operation of each TivoliAccess Manager server:

Name Configuration File Configuration File Location

Policy server ivmgrd.conf UNIX: install_path/etc/ivmgrd.confWindows: install_path\etc\ivmgrd.conf

Authorization server ivacld.conf UNIX: install_path/etc/ivacld.confWindows: install_path\etc\ivacld.conf

Active Directoryregistry server

activedir.conf Windows: install_path\etc\activedir.conf

Domino registryserver

domino.conf Windows: install_path\etc\domino.conf

LDAP server ldap.conf UNIX: install_path/etc/ldap.confWindows: install_path\etc\ldap.conf

Tivoli AccessManager Baseconfiguration file

pd.conf UNIX: install_path/etc/pd.confWindows: install_path\etc\pd.conf

Tivoli Access Manager Base program files are installed in the following defaultdirectories:

UNIX: /opt/PolicyDirector/Windows: C:\Program Files\Tivoli\Policy Director\

This guide uses the install_path variable to represent this root directory. All relativepath names expressed in the Tivoli Access Manager configuration files are relativeto this root directory.

Configuration files are ASCII text-based and can be edited using a common texteditor. The configuration files contain parameter entries in the following format:parameter=value

Web PortalManager

MasterAuthorization

Database

UserRegistry

Policy Server(pdmgrd)

Authzn Server(pdacld)

ReplicaAuthzn

Database

Figure 28. Tivoli Access Manager server components


The initial installation of Tivoli Access Manager establishes default values for mostparameters. Some parameters are static and never change; others can be modifiedto customize server functionality and performance.

Note: After editing a configuration file, you must stop and restart the Tivoli AccessManager server before the changes take effect.

Each file contains sections, or stanzas, containing one or more parameters for aparticular configuration category. The stanza labels appear within brackets[stanza-name].

For example, the [ssl] stanza in ivmgrd.conf defines the SSL configurationsettings for the policy server. The stanza [ldap] defines configuration required bythe policy server to communicate 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 filesto ensure their integrity.

Tivoli Access Manager utilitiesThe following Tivoli Access Manager utilities are discussed in the Tivoli AccessManager Command Reference. Table 1 lists available utilities and their purposes. Notethat the pdadmin command line interface also provides commands that assist introubleshooting problems. For example, the pdadmin server task command,includes stats and trace options, which enable you to enable statistics gatheringand capture information about error conditions. For more information about usingthese commands, see the Tivoli Access Manager Problem Determination Guide.

Table 1. Tivoli Access Manager utilities

Utility Purpose

bassslcfg Performs SSL configuration tasks.

ezinstall_* Sets up complete Tivoli Access Managersystems using batch files (Windows) orscripts (UNIX).

install_pdrte.exe Sets up a Tivoli Access Manager runtimesystem with the following softwarepackages:

v IBM Global Security Toolkit

v IBM Directory client

v Tivoli Access Manager runtimeenvironment

mgrsslcfg Performs SSL configuration tasks.

pdacld_dump Used to validate and maintain Tivoli AccessManager policy (authorization) databases.

pdbackup Backs up, restores, and extracts Tivoli AccessManager data.

pdconfig Configures Tivoli Access Managercomponents.

pdinfo Gathers and stores current informationabout your Tivoli Access Managersystem.

Chapter 7. Managing Tivoli Access Manager servers 91

Table 1. Tivoli Access Manager utilities (continued)

Utility Purpose

pdjrtecfg Configures the Tivoli Access ManagerJavaRuntime Environment.

pd_start Stops/starts servers and displays serverstatus.

pdversion Lists versions of Tivoli Access Managercomponents installed.

svrsslcfg Configures resource managers into thesecure domain. Also performs SSLconfiguration tasks.

Starting and stopping Tivoli Access Manager serversThis section describes how to start and stop server processes:v “Starting and stopping servers on UNIX systems”v “Starting and stopping servers on Windows systems” on page 93

Starting and stopping servers on UNIX systemsServer processes are normally enabled and disabled through automated scripts thatrun at system startup and shutdown.

In a UNIX environment, you can also use the pd_start script to manually start andstop the server processes. This technique is useful when you need to customize aninstallation or when you need to perform troubleshooting tasks. You can runscripts only on the local machine. Use the Web Portal Manager to stop and startservers remotely.

The general syntax for pd_start is as follows:# pd_start {start|restart|stop|status}

You can run the pd_start utility from any directory. The script is located in thefollowing directory:/opt/PolicyDirector/bin/

Start the Tivoli Access Manager Servers using the pd_start utilityUse the pd_start utility to start all Tivoli Access Manager servers not currentlyrunning on a particular machine:# pd_start start

This script waits until all servers have started before returning the prompt.

Start individual servers manuallyYou can manually start the servers individually by executing the server directly.

You must perform the startup commands as an administration user, such as root.

Start the Tivoli Access Manager servers in the following order:1. For the policy server (pdmgrd), enter the following:

install_path/bin/pdmgrd

2. For the authorization server (pdacld), enter the following:install_path/bin/pdacld


Restart the Tivoli Access Manager servers using the pd_startutilityUse the pd_start utility to stop all Tivoli Access Manager servers on a particularmachine and then restart the servers:pd_start restart

This script waits until all servers have started before returning the prompt.

Stop the Tivoli Access Manager servers using the pd_start utilityUse the pd_start utility to stop all Tivoli Access Manager servers on a particularmachine in the correct order:pd_start stop

This script waits until all servers have stopped before returning the prompt.

Displaying server status using the pd_start utilityUse the pd_start command to display server status:pd_start status

Tivoli Access Manager Servers:Server Enabled Running

pdmgrd yes yeswebseald no nopdacld yes no

Starting and stopping servers on Windows systemsUse the Windows NT Services Control Panel to start and stop the server processesmanually. This can be useful when customizing an installation or whentroubleshooting. Administrative privileges are required to use this utility.

You can start and stop the Tivoli Access Manager servers all at once orindividually. The servers generally must be stopped and started in the correctorder.

Using the Services Control Panel to stop and start serversThe AutoStart Service automatically starts each of the Tivoli Access Managerservers whenever the Startup configuration is set to Automatic. After the serversstart, the AutoStart Service exits.

You can also use the Services Control Panel to manually start and stop theindividual servers:1. Open the Windows Control Panel.2. Double-click the Services icon.

The Services dialog appears.3. From the list box, select the Tivoli Access Manager servers according to the

sequence indicated in Steps 4 and 5.4. Stop the Tivoli Access Manager servers in the following order:

v authorization serverv policy server

5. Start the Tivoli Access Manager servers in the following order:v policy serverv authorization server


6. Click the appropriate control option button (Start, Stop, Startup) from theright-hand side of the box.

7. To prevent automatic starting of a Tivoli Access Manager server by theAutoStart Service, use the Startup button to set that server to Disabled.

Automating server startup at boot timeParameters for automating server startup are located in the [pdrte] stanza of thepd.conf configuration file.

Policy serverWhen the PDMgr package is installed, the policy server automatically starts aftereach system reboot:[pdrte]boot-start-ivmgrd = yes

To prevent automatic pdmgrd startup, set:boot-start-ivmgrd = no

Note: Each secure domain must contain only one. Do not install and run pdmgrdon more than one server per secure domain.

Authorization serverWhen the PDAcld package is installed, the authorization server daemonautomatically starts after each system reboot:[pdrte]boot-start-ivacld = yes

To prevent automatic pdacld startup, set:boot-start-ivacld = no

Policy server administrationThe policy server manages the master authorization policy database and maintainslocation information about other Tivoli Access Manager servers in the securedomain. The policy server typically requires very little administration orconfiguration. This section describes configuration tasks available to theadministrator.v “Replicating the authorization database” on page 94v “Setting the number of update notifier threads” on page 96v “Setting the notification delay time” on page 96

Replicating the authorization databaseA Tivoli Access Manager administrator can make security policy changes to thesecure domain at any time. A primary responsibility of the policy server is to makethe necessary adjustments to the master authorization database to reflect thesechanges.

When the policy server makes a change to the master authorization database, itcan send out notification of this change to all authorization servers (with replicadatabases). The authorization servers must then request a database update fromthe master authorization database.


Note: Additionally, client servers can check for database updates by polling thepolicy server at regular intervals. Polling configuration for a WebSEALclient, for example, is explained in the IBM Tivoli Access Manager WebSEALAdministrator’s Guide.

Tivoli Access Manager allows you to configure update notifications from the policyserver to be an automatic process or a manually controlled task. Theauto-database-update-notify parameter is located in the [ivmgrd] stanza of theivmgrd.conf configuration file. By default, the parameter is set to yes (updatenotification is automatically performed by the policy server):[ivmgrd]auto-database-update-notify = yes

This automatic setting is appropriate for environments where database changes arefew and infrequent. When you configure update notification to be automatic, youmust also correctly configure the max-notifier-threads and notifier-wait-timeparameters. For more information on max-notifier-threads and notifier-wait-timeparameters, see “Setting the number of update notifier threads” on page 96 and“Setting the notification delay time” on page 96.

When you configure update notification to be manual, manual application of thepdadmin server replicate command controls this event.[ivmgrd]auto-database-update-notify = no

This manual setting is appropriate for environments where database modificationsoccur frequently and involve substantial changes. In some cases several databasemodifications can generate many update notifications that soon become obsoletebecause of the continuing changes to the master database. These obsoletenotifications cause unnecessary network traffic.

The manual control of update notification allows you to complete the process ofmodifying the master authorization database before update notifications are sentout to authorization servers with database replicas.

In manual mode, update notification uses the notifier thread pool (as it does inautomatic mode). Therefore, the manual mode setting is affected by themax-notifier-threads parameter setting. For more information on themax-notifier-threads parameter, see “Setting the number of update notifierthreads” on page 96.

Using the pdadmin server replicate commandWhen you configure update notification to be manual, manual application of thepdadmin server replicate command controls this event. The command has thefollowing syntax:pdadmin> server replicate [-server server-name]

If the optional server-name argument is specified, only that server is notified ofchanges to the master authorization database. A response is returned indicating thesuccess or failure of the notification and the replication.

If the server-name argument is not specified, all configured authorization serversreceive update notifications. A successful response indicates only that the policyserver has begun sending 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 policy server is responsible for synchronizing all database replicas in thesecure domain. When a change is made to the master database, notification threadsdo the work of announcing this change to all replicas. Each replica then has theresponsibility to download the new information from the master.

The policy server configuration file, ivmgrd.conf, contains a parameter for settingthe maximum number of update notifier threads. This pool of threads allowssimultaneous (parallel) notification.

For example, to concurrently notify 30 replicas of a database change, the threadpool should be set to at least 30. If there are more than 30 replicas, another roundof notifications occurs (in this example, 30 at a time). All replicas are guaranteed tobe notified, regardless of the value of this parameter.

The performance goal of the update notifier threads value is to announce adatabase change as quickly as possible. Generally the value should be set to equalthe number of existing replicas. This results in the performance advantage of asingle pool of threads quickly accomplishing the notification task to all replicas atonce.

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 policy server is instructed to make a change to the master authorizationdatabase, it waits for a default period of time before sending out notifications todatabase replicas. The default time delay is set at 15 seconds. This time delay isreset with each subsequent change to the database.

The purpose of the time delay is to prevent the policy server from sendingindividual replica notifications for each of a series of database changes. The timedelay helps to ensure optimal performance of the Tivoli Access Manager system.

This performance feature is particularly important for environments where batchchanges are made to the authorization database. It is not efficient for policychanges to be sent to database replicas until all changes 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 ofthe ivmgrd.conf configuration file. For example:[ivmgrd]notifier-wait-time = 20

By default, the value is set to 15 seconds.


Chapter 8. Managing registries

This chapter contains a subset of user registry tasks that are specific to theinstallation of Tivoli Access Manager. For common administrative tasks for yourparticular registry (tasks that are not Tivoli Access Manager-specific), refer to thedocumentation that came with your user registry product.

This chapter contains the following sections:v “LDAP-specific tasks”v “Active Directory-specific tasks” on page 106v “Novell-specific tasks” on page 108

LDAP-specific tasksLDAP is a protocol that runs over TCP/IP. The LDAP protocol standard includeslow-level network protocol definitions plus data representation and handlingfunctionality. A directory that is accessible through LDAP is commonly referred toas an LDAP directory.

This section contains the following topics:v “LDAP fail-over configuration”v “Using valid characters for LDAP user and group names” on page 100v “Applying Tivoli Access Manager ACLs to new LDAP suffixes” on page 101

LDAP fail-over configurationThe Lightweight Directory Access Protocol (LDAP) defines a standard method foraccessing and updating information in a directory. Directories are usually accessedusing the client/server model of communication. Any server that implements theLDAP protocol is an LDAP directory server.

The LDAP distributed architecture supports scalable directory services with serverreplication capabilities. Server replication improves the availability of a directoryservice. IBM Directory replication is based on a master-subordinate model. iPlanetDirectory Server replication is based on a supplier/consumer model. Tivoli AccessManager still treats this as a master-subordinate relationship.

The combination of a master server and multiple replicated servers helps ensurethat directory data is always available when needed. If any server fails, thedirectory service continues to be available from another replicated server. TivoliAccess Manager supports this replication capability.

The master-subordinate replication modelReplication involves two types of directories: master and replica. LDAP refers tothe master as master server and to the replica as replica server. All updates aremade on the master server and these updates are subsequently propagated to thereplica servers. Each replica server database contains an exact copy of the masterserver’s directory data.

Changes to the directory can be made only to the master server, which is alwaysused for write operations to the directory. Either the master or the replicas can be


used for read operations. When the original master server is out of service for anextended period of time, a replica server can be promoted as a master server toallow write operations to the directory.

Tivoli Access Manager fail-over capability for LDAP serversTivoli Access Manager connects to the LDAP master server when it starts up. If theLDAP master server is down for any reason, the Tivoli Access Manager servermust be able to connect to an available LDAP replica server for any readoperations.

Many operations, especially those from regular users, are read operations. Theseinclude operations such as user authentication and signon to back-end junctionedWeb servers. After proper configuration, Tivoli Access Manager performs fail-overto a replica server when it cannot connect to the master server.

You can find the configuration parameters for LDAP fail-over in the [ldap] stanzaof the ldap.conf configuration file:

UNIX: /opt/PolicyDirector/etc/ldap.confWindows: install_path\etc\ldap.conf

Master server configurationIBM Directory supports the existence of a single read-write master LDAP server.iPlanet Directory Server supports multiple read-write LDAP servers. Tivoli AccessManager treats the iPlanet supplier server as the master server for configurationpurposes.

The active configuration lines in the ldap.conf file represent the parameters andvalues for this master LDAP server. You determine these values during TivoliAccess Manager configuration. For example:[ldap]enabled = yeshost = outbackport = 389ssl-port = 636max-search-size = 2048

Parameter Description

enabled Tivoli Access Manager uses an LDAP user registry. Values areyes and no.

host The network name of the machine where the LDAP masterserver 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 Tivoli Access Manager limit for an LDAP client search ofdatabase items - such as a request for the Web Portal Manager tolist users from the LDAP database.

If you make a change to the LDAP database, such as adding a new user accountthrough the Web Portal Manager, Tivoli Access Manager always uses theread-write (master) LDAP server.


Replica server configurationIBM Directory supports the existence of one or more read-only replica LDAPservers. iPlanet Directory Server supports the existence of one or more read-onlyreplica LDAP servers referred to as consumers.

You must add lines to the [ldap] stanza that identifies any replica servers availableto Tivoli Access Manager. Use the following syntax for each 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 or 636.

type The functionality of the replica server - either read-only orread-write. Normally, use read-only. A read-write type wouldrepresent a master server.

preference A number from 1 - 10. The server with the highest preferencevalue is chosen for LDAP connections. See “Setting preferencevalues for replica LDAP servers”.

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 restart Tivoli AccessManager.

Setting preference values for replica LDAP serversEach replica LDAP server must have a preference value (1-10) that determines itspriority for selection as:v The primary read-only access server, orv A backup read-only server during a fail-over

The higher the number, the higher the priority. If the primary read-only server failsfor any reason, the server with the next highest preference value is used. If two ormore servers have the same preference value, a least-busy load balancingalgorithm determines which one is selected.

Remember that the master LDAP server can function as both a read-only and aread-write server. For read-only access, the master server has a hard-coded defaultpreference setting of 5. This allows you to set replica servers at values higher orlower than the master to obtain the required performance. For example, withappropriate preference settings, you could prevent the master server from handlingeveryday read operations.

You can set hierarchical preference values to allow access to a single LDAP server(with fail-over to the other servers), or set equal preferences for all servers andallow load balancing to dictate server selection.

The following table illustrates some possible preference scenarios. “M” refers to themaster (read-only/read-write) LDAP server; “R1, R2, R3” refer to the replica(read-only) LDAP servers.

Chapter 8. Managing registries 99

M R1 R2 R3 Fail-over preference

5 5 5 5 All servers have the same preference values. Loadbalancing determines which server is selected for eachaccess operation.

5 6 6 6 The three replica servers have the same preferencevalue. This value is higher than the master servervalue. Load balancing determines server selectionamong the three replicas. The master is used only ifall three replica servers become unavailable.

5 6 7 8 Server 3 (with the highest preference value) becomesthe primary server. If server 3 fails, server 2 becomesthe primary server because it has the next highestpreference value.

Preference values affect only read-only access to the LDAP database. Tivoli AccessManager always uses the master (read-write) server when you need to make achange to the LDAP database.

Also note that some Tivoli Access Manager daemons (such as the policy server)override the preference settings in their configuration files to indicate that theread-write server is preferred. This override occurs because those daemons usuallymake update operations that should go to the master LDAP server.

Server pollingIf an LDAP server does fail, Tivoli Access Manager continuously polls the server tocheck for its return to active duty. The poll time is 10 seconds.

Using valid characters for LDAP user and group namesWhen using LDAP as the user registry, the set of valid characters allowed within auser or group name is determined by the following Internet Engineering TaskForce (IETF) Request for Comments (RFC):v 2253 ″Lightweight Directory Access Protocol (v3): UTF-8 String Representation of

Distinguished Names″

v 2254 ″The String Representation of LDAP Search Filters″

The specific LDAP server can also dictate the validity of these characters.

In general, you can use special characters within a Distinguished Name. However,certain special characters require an additional escape character. The followingspecial characters must be escaped when used in a Distinguished Name:v + (plus)v \ (backslash)v ; (semicolon)v , (comma)

For example, to create a user containing a semicolon using the pdadmin utility:pdadmin> user create "user;one" "cn=user\;one,o=tivoli,c=us""user;one" "user;one" password1

If you use special characters when using pdadmin from a command line, encloseeach argument of the user or group command with double quotation marks. Thedouble quotation marks allow the argument to be entered without being subject tointerpretation by the operating system shell command processor.


Due to the variability of special character handling in general, avoid using specialcharacters.

Applying Tivoli Access Manager ACLs to new LDAP suffixesWhen an LDAP administrator adds LDAP suffixes after the initial configuration ofTivoli Access Manager, the administrator must apply the appropriate AccessControl Lists (ACLs) to allow Tivoli Access Manager to manage users and groupsdefined in these new suffixes.

For IBM Directory, use the Directory Management Tool to apply ACLs. For iPlanetDirectory Server, use the iPlanet Console 5.0.

Use the appropriate LDAP administration interface to apply the following ACLs toevery new Tivoli Access Manager suffix:

LDAP Group Access Control

cn=SecurityGroup,secAuthority=Default

v full access

cn=ivacld-servers,cn=SecurityGroup,secAuthority=Default

v read

v search

v compare

cn=remote-acl-users,cn=SecurityGroup,secAuthority=Default

v read

v search

v compare

These controls apply when the administrator has selected LDAP for the TivoliAccess Manager user registry and a new LDAP suffix has been created after TivoliAccess Manager is initially configured. It is assumed that you are the Tivoli AccessManager administrator and are familiar with both Tivoli Access Manager andLDAP. It is further assumed that, as administrator, you have the proper authorityto update the LDAP Directory Information Tree.

When Tivoli Access Manager is configured, it attempts to apply appropriate ACLsto every LDAP suffix that exists at that time in the LDAP server. This accesscontrol allows Tivoli Access Manager to create and manage user and groupinformation within these LDAP suffixes.

However, if a suffix is created after Tivoli Access Manager has been configured,and Tivoli Access Manager must later be able to create and manage user andgroup information within this new suffix, then the appropriate access controls needto be applied manually. Without these access controls, Tivoli Access Manager doesnot have the appropriate LDAP permission to create and manage user and groupinformation specified to be within this new suffix.

To apply the appropriate access controls to the newly created LDAP suffix, performthe following steps for either the IBM Directory or the iPlanet Directory Server,depending on the LDAP server type being used.


Note that the procedures assume that the newly created suffix is calledo=neworg,c=us. You should substitute the actual newly created suffix for this valuein the following descriptions.

Procedures for the IBM Directory serverThe following steps describe how to apply the appropriate Tivoli Access Manageraccess controls to the newly created suffix for the IBM Directory Server.1. Start the LDAP Directory Management Tool (DMT) with one of the following

commands:On Windows systems: Start → Programs → IBM Directory Server 4.1 →Directory Management Tool

On UNIX systems:# /usr/bin/dmt

2. The following warning might appear:Warning: Entry o=neworg,c=us does not contain any data.

If the warning appears, make a note of it and continue with step 3.3. Click the Add Server button in the left pane. The Add Server window

appears.4. Ensure that Simple is selected for the Authentication Type field.5. 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 LDAP administrator

User Password: abc123 Password of the LDAPadministrator

6. Click OK. The Directory Management Tool page appears.7. Verify the server name in the upper part of the left frame. For example,

ldap://ibm007.ibm.com:389

8. From the tree structure on the left, select Directory Tree → Browse Tree. Thefollowing warning might appear:Warning: Entry o=neworg,c=us does not contain any data.

9. Skip to step 10 if you have not seen the following message:Warning: Entry o=neworg,c=us does not contain any data.

If you have seen this message (as you recorded in step 2), you must create anentry for the suffix. 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 LDAP Entry dialog box is

displayed.b. Set the entry type to Organization. Set the parent DN to c=us. Set the

entry DN to o=neworg. Click OK. The entry page for organization isdisplayed within the Add an LDAP dialog box.

c. Enter the organization name, neworg, in the Attributes section at the o:label.

d. Click Add. The Browse Directory Tree page is displayed.10. Click Directory Tree → Refresh Tree in the left pane.


11. Highlight the newly created suffix in the Browse Tree pane on the right.12. Click the ACL button in the right pane. The current access control list settings

for the suffix are displayed in the Edit an LDAP ACL window.13. In the Subject area of the Edit an LDAP ACL window, enter the following

Distinguished Name:cn=SecurityGroup,secAuthority=Default

Check the group type and click Add.14. When the window is displayed, make the following selections:

v In the DN entry box, select Descendant directory tree entries inherit fromthis entry.

v In the Rights box, for Add child and Delete entry, select Grant.v In the Security class box, for each security class (Normal, Sensitive, and

Critical), select Grant for each permission (Read, Write, Search, andCompare).

Click OK.15. Highlight the newly created suffix in the Browse Tree pane on the right.16. Click the ACL button in the right pane. Verify that the

cn=SecurityGroup,secAuthority=Default group is listed and the settings forthe group are correct. Group names are not case-sensitive.

17. In the subject area of the Edit an LDAP ACL window, enter the followingDistinguished Name:cn=ivacld-servers,cn=SecurityGroup,secAuthority=Default

Select the group Type and click Add.18. When the window is displayed, make the following selections:


v In the Rights box, for Add child and Delete entry, select Unspecified.v In the Security class box, for the Normal security class, select Grant for the

Read, Search and Compare permissions.v In the Security class box, for the Normal security class, select Unspecified

for the Write permissions.v In the Security class box, for the Sensitive and Critical security classes,

select Unspecified for all permissions.

Click OK.19. Highlight the newly created suffix in the Browse Tree pane on the right. Click

the ACL button in the right pane. Verify that the cn=ivacld-servers,cn=SecurityGroup,secAuthority=Default group is listed and thesettings for the group are correct. Group names are not case-sensitive.

20. In the Subject area of the Edit an LDAP ACL window, enter the followingDistinguished Name:cn=remote-acl-users,cn=SecurityGroup,secAuthority=Default

Select the group Type and click Add.21. When the window is displayed, make the following selections:


v In the Rights box, select Unspecified for Add child and Delete entry.


v In the Security class box, for the Normal security class, select Grant for theRead, Search, and Compare permissions.

v In the Security class box, for the Normal security class, select Unspecifiedfor the Write permission.

v In the Security class box, for the Sensitive and Critical security classes,select Unspecified for each permission (Read, Write, Search, andCompare).

Click OK.22. Click Exit to close the Directory Management Tool.

Procedures for iPlanet Directory ServerNote that these procedures describe the creation of ACLs for suffixes using theiPlanet Console 5.0.1. Start the iPlanet Console 5.0 with one of the following commands:

v On UNIX systems, enter the following from the iPlanet Directory serverinstall directory:# ./startconsole

v On Windows systems, click: Start → Programs → iPlanet Server Products →iPlanet Console 5.0

2. Enter the User ID for the LDAP administrator. This is usually cn=DirectoryManager. Enter the password and the Administration URL. Click OK.

3. Select the Domain to be used by Tivoli Access Manager.4. Expand the server name and Server Group.5. Select the entry labeled Directory Server. Configuration information 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 displayed in the left

pane, skip to step 8.If the newly created suffix does not appear in the left pane, you must createan entry for the new suffix before applying access controls to the suffix.Follow these steps to create the entry:a. Highlight the name of the server at the top of the directory tree. Click

Object → New Root Object. A list of root suffixes is displayed.b. Select o=neworg,c=us from the list of root suffixes. The New Object

selection window is displayed.c. In the New Object selection window, scroll down and select Organization

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. Create the entry typeand name that corresponds to your actual suffix.

f. Click View → Refresh. The new suffix entry appears in the left pane.8. Highlight the neworg entry in the left pane. Click Object → Set Access

Permissions. The Manage Access Control for o=neworg,c=us window isdisplayed.

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 window is 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 text correctly. Correctany errors until the syntax passes the check.

14. Click OK. The Manage Access Control for o=neworg,c=us window isdisplayed.

15. Click New. Specify the ACI name as PD Servers GROUP - ALLOW READ.16. Highlight the All Users name and click Remove.17. Click Edit Manually. The Edit ACI for o=neworg,c=us window is displayed.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=SecurityGroup,secAuthority=Default";)



20. Click New. Specify the ACI name as PD Remote ACL Users GROUP -ALLOW READ.

21. Highlight the All Users name and click Remove.22. Click Edit Manually. The Edit ACI for o=neworg,c=us window is displayed.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=SecurityGroup,secAuthority=Default";)



25. Click New. Specify the ACI name as PD Deny-Others1.26. Highlight the All Users name and click Remove.27. Click Edit Manually. The Edit ACI for o=neworg,c=us window is displayed.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=SecurityGroup,secAuthority=Default ||ldap:///cn=ivacld-servers,cn=SecurityGroup,secAuthority=Default";)




30. Click New. Specify the ACI name as PD Deny-Others2.31. Highlight the All Users name and click Remove.32. Click Edit Manually. The Edit ACI for o=neworg,c=us window is displayed.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=SecurityGroup,secAuthority=Default ||ldap:///cn=ivacld-servers,cn=SecurityGroup,secAuthority=Default";)



35. Click OK to close the Manage Access Control for o=neworg,c=us window.36. Click Console → Exit to exit the console.

Active Directory-specific tasksMicrosoft Active Directory is an infrastructure supported by Windows 2000 thatincludes a network management of directory objects, and has the capability tocommunicate with other directory services.

This section contains the following topics:v “Setting up Microsoft Windows 2000 Domain Name System (DNS) for Active

Directory”v “Updating the Tivoli Access Manager schema” on page 107v “Adding a Tivoli Access Manager user to the Active Directory system group” on

page 108

Setting up Microsoft Windows 2000 Domain Name System(DNS) for Active Directory

Active Directory uses DNS as a domain controller location mechanism. Thisenables computers to find the IP addresses of the domain controllers. Formulti-domain mode, at least two domains are required: a primary domain, a childdomain of the primary domain, or a domain tree in the forest. For fail-over, at leasttwo primary domain controllers are needed.

You can set up the DNS server before configuring the domain controllers or whenyou configure the primary Active Directory domain controller. There are two waysto setup DNS for Active Directory:1. Configure DNS on the forest root2. Use a separate DNS server

If configuring DNS on the forest root, DNS is configured automatically on thathost if this is the first domain controller configured. This domain controller and itsreplicas serve as the DNS servers.


The DNS server is not necessary on the host that is the domain controller in theforest. You can use any DNS server. If you are not using a Windows 2000-basedDNS server, contact your DNS administrator or a DNS server vendor to find outwhether your server supports the required standards. If the server does notsupport the required standards or the zone cannot be configured to allow dynamicupdates, you need to modify the existing DNS infrastructure.

Adding a new domain name to a DNSTo add a new domain name to a DNS, do the following:1. Click Start→Programs→Administrator Tools→DNS to open the DNS.2. Expand the host name and Forward Lookup Zones.3. Create a new zone (new root domain) or child domain.4. If using a separate DNS, open the domain properties and change the Allow

dynamic updates field to Yes.

Updating the Tivoli Access Manager schemaIn order to perform all Tivoli Access Manager operations, you need to add a TivoliAccess Manager schema on Active Directory. The Tivoli Access Manager schemaadds to the schema master, which is a root domain controller in the forest. TheTivoli Access Manager schema automatically updates to the schema master duringTivoli Access Manager configuration. You need to manually update the TivoliAccess Manager schema only when Tivoli Access Manager is configured to a singleActive Directory domain (not the root domain).

Note: Before updating the Tivoli Access Manager schema, verify that it is notalready on the schema master. The Tivoli Access Manager schema needs tobe updated only once in the forest.

To verify if the Tivoli Access Manager schema is updated on your system, do thefollowing:1. In your domain controller, go to Start → Programs → Administrative Tools →

Active Directory Users and Computers. The Active Directory Users andComputers dialog appears.

2. In this dialog, expand the domain that contains the Users folder.3. Right click on the Users folder. A menu appears.4. Select New in the menu. Another menu appears.5. If a list of Tivoli Access Manager classes for Active Directory appear in the

menu in the URAF-xxx form, (for example, URAF-container), then the TivoliAccess Manager schema is already on the schema master. You do not need toupdate the Tivoli Access Manager schema.

To manually update the Tivoli Access Manager schema, do the following:1. Install Tivoli Access Manager runtime on the root domain controller.2. Run the aminstall_dir\sbin\adschema_update –u AMConfID –p AMConfPWD

commandwhere:v aminstall_dir is the directory that installs Tivoli Access Managerv AMConfID is the Tivoli Access Manager configuration login IDv AMConfPWD is the Tivoli Access Manager configuration login password

3. After you verify that the Tivoli Access Manager schema has been added to theschema master, you can uninstall Tivoli Access Manager runtime from the rootdomain.


Note: The Tivoli Access Manager schema propagation takes approximately fiveminutes from the schema master to add to the non-root domain controller.

Adding a Tivoli Access Manager user to the Active Directorysystem group

In order to have sufficient access to modify user and group attributes, a TivoliAccess Manager user must be added to the appropriate Active Directory systemgroup. To add a user to an Active Directory system group on a system whereActive Directory is configured as a Tivoli Access Manager user registry, and do thefollowing:1. Login as Administrator.2. Go to Start → Programs → Administrative Tools.3. Select Active Directory Users and Computers from the menu. The Active

Directory Users and Computers dialog appears.4. On the left navigation panel, go to Tivoli PD Domains → default → system →

users, where the users container of the Tivoli Access Manager user registrycontainer is located.

5. From the list of users displayed, select the Tivoli Access Manager user thatyou want to add to the Active Directory system group.

6. Right click on the Tivoli Access Manager user and select Properties. TheProperties dialog for the selected Tivoli Access Manager user is displayed.

7. Click the Member Of tab.8. Click the Add button. The Select Groups dialog appears.9. Select the appropriate group that you want the Tivoli Access Manager user to

become a member of and click the Add button. Do one of the following:v If the purpose is to modify user or group attributes for Active Directory

single domain, select the Domain Admins group.v If Tivoli Access Manager is configured using Active Directory multiple

domain, select the Enterprise Admins group.v If you want to add the user to multiple groups, repeat the process.

10. Click the OK button to close all opened dialogs.

Novell-specific tasksThe Novell eDirectory Server (NDS) user registry is supported by Tivoli AccessManager through the LDAP server. This section describes how to install the TivoliAccess Manager schema using an LDAP interface.

Updating Tivoli Access Manager schemaIf you are installing a new Tivoli Access Manager secure domain, the Tivoli AccessManager schema is installed automatically with the configuration of Tivoli AccessManager policy server. However, there are some manual changes that must bedone prior to configuring the Tivoli Access Manager policy server.

Note: This schema assumes that the current directory does not use the X.500 objectclasses of inetOrgPerson or groupOfNames. These classes are by defaultmapped into the eDirectory classes of User and Group respectively.

To use the schema definition file to update the schema, do the following:1. Right click the LDAP group object (not LDAP server) and select Properties

from the drop-down menu.


2. Select the Class Map tab and the table of LDAP class names. NDS class namesare displayed.

3. Delete the entries with LDAP classes of inetOrgPerson and groupOfNames.4. Click the Apply button, and then click the Close button.5. Select the Attribute Map tab and the table of LDAP attribute names. NDS

attribute names are displayed.6. Scroll through the table and find the NDS attribute, Member. Check the value

of the corresponding LDAP attribute. If the LDAP attribute is a member, thenno change is needed. If the attribute is showing the default value ofuniqueMember, then it needs to be modified.

7. Click the Modify button. The Attribute Mapping dialog is displayed.8. The Primary LDAP attribute field contains the value, uniqueMember. Change

the Primary LDAP attribute field to the value, member.9. The Secondary LDAP attribute field contains the value, member. Change the

Secondary LDAP attribute field to the value, uniqueMember.10. Click the OK button. The Attribute Mapping dialog is cleared. Then, continue

as follows:v If you are using Solaris, proceed to Step l4.v If you are using Windows NT, then you might have to add another

mapping for the LDAP attribute, ndsHomeDirectory. Click the Add buttonon the right hand side of the Attribute Mappings panel. The AttributeMapping window appears again.

11. From the NDS Attribute field drop-down menu, select the Home Directoryvalue.

12. In the Primary LDAP Attribute field, select the ndsHomeDirectory value.13. Click the OK button. The Attribute Mapping dialog is cleared.14. Click the OK button on the Properties dialog. The Properties dialog is cleared.


Chapter 9. Logging and auditing server activity

Tivoli Access Manager provides a number of logging and auditing capabilities. Logfiles can capture any error and warning messages generated by Tivoli AccessManager servers. Audit trail files can capture authorization, authentication,management, and HTTP events occurring on the Tivoli Access Manager servers.

This chapter contains the following sections:v “Introduction to logging and auditing” on page 111v “Logging Base serviceability messages” on page 112v “Tivoli Access Manager audit trail files” on page 113v “Audit trail file format” on page 116v “Audit trail file contents” on page 117

Introduction to logging and auditingThe contents of log and audit trail files can be a useful source of information whenmonitoring and troubleshooting the activity of Tivoli Access Manager servers.

Audit trail filesAudit trail files are used by the Tivoli Access Manager servers to store records ofserver activity. The output of a specific server event is called a record. An audittrail is a collection of multiple records that document the server activity. All TivoliAccess Manager audit trail files are in ASCII format.

Tivoli Access Manager audit trail files record events for the following servers:v policy server (pdmgrd)v authorization server (pdacld)

See “Tivoli Access Manager audit trail files” on page 113.

See “Audit trail file format” on page 116.

See “Audit trail file contents” on page 117.

Documentation convention: install_pathThe install_path variable used throughout this chapter has the followinginterpretations, 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 during the installation ofthe Tivoli Access Manager software.


Logging Base serviceability messagesTivoli Access Manager Base serviceability messages are controlled by the TivoliAccess Manager Base routing file. The routing file is located in the followingdirectory:

UNIX:/opt/PolicyDirector/etc/

Windows:C:\Program Files\Tivoli\Policy Director\etc\

The routing file is an ASCII file that contains additional information in the form ofcomment lines. Entries in this configuration file determine the types ofserviceability messages that are logged. Enable any entry by removing thecomment character (#). The routing file includes the following default entries:

UNIX:FATAL:STDOUT:-;FILE:/var/PolicyDirector/log/msg__fatal.logERROR:STDOUT:-;FILE:/var/PolicyDirector/log/msg__error.logWARNING:STDOUT:-;FILE:/var/PolicyDirector/log/msg__warning.logNOTICE:FILE.10.100:/var/PolicyDirector/log/msg__notice.log#NOTICE_VERBOSE:STDOUT:-;FILE:/var/PolicyDirector/log/msg__verbose.log

Windows:FATAL:STDERR:-;FILE:%PDDIR%/log/msg__fatal.logERROR:STDERR:-;FILE:%PDDIR%/log/msg__error.logWARNING:STDERR:-;FILE:%PDDIR%/log/msg__warning.logNOTICE:FILE.10.100:%PDDIR%/log/msg__notice.log

Note: On a Windows system, the special environment variable PDDIR is set at runtime to the Tivoli Access Manager installation directory.

By default, when Tivoli Access Manager Base runs in the foreground, messages arehandled in the following manner:1. Messages are sent to the screen (STDOUT, STDERR).2. Messages are sent to the appropriate configured log file entries in the log

directory (msg__fatal.log, msg__error.log, msg__warning.log,msg__notice.log).

By default, when Tivoli Access Manager Base runs in the background, messagesare handled in the following manner:1. Messages are redirected from STDOUT and STDERR and sent to the

appropriate server log file as defined in the [server_name] stanza of theappropriate server configuration file.

Server ConfigurationFile

Log File Location

Policy server

(pdmgrd)

ivmgrd.conf UNIX:[ivmgrd]log-file=/var/PolicyDirector/log/msg__ivmgrd.log

Windows:[ivmgrd]log-file=install_path\log\msg__ivmgrd.log


Server ConfigurationFile

Log File Location

Authorization server

(pdacld)

ivacld.conf UNIX:[ivacld]log-file=/var/PolicyDirector/log/msg__ivacld.log

Windows:[ivacld]log-file=install_path\log\msg__ivacld.log

2. Messages are also sent to the appropriate configured log file entries in the logdirectory (msg__fatal.log, msg__error.log, msg__warning.log,msg__notice.log). This is configured in the routing configuration file.

To enable msg__verbose.log, uncomment the NOTICE_VERBOSE line.

The FILE syntax for the NOTICE message controls log roll over and file recycling:FILE.max_files.max_records

The max_files value specifies the number of files that are used.

The max_records value specifies the maximum number of entries per file.

In the default example above, the max_files and max_records are not specified exceptfor the msg__notice file. The default FILE entry for the configured log filesspecifies that log files are not to be recycled or rolled over. The files are configuredto grow sequentially without limit. When configured to grow without limit, the logfiles need to be replaced or pruned periodically.

The msg__notice file is configured with FILE.10.100 which means there are 10 filescreated, each with a maximum of 100 entries. The files are named:msg__notice.log.1msg__notice.log.2...msg__notice.log.10

The messages wrap around to the first file after the last file has reached its limit orwhen the server is stopped and restarted. When a log file is reused, the existingrecords are written over (erased).

Tivoli Access Manager audit trail filesAuditing is defined as the collection of data about system activities that affect thesecure operation of the Tivoli Access Manager authorization process. Each TivoliAccess Manager server can capture audit events whenever any security-relatedauditable activity occurs.

Audit events are saved as audit records that document the specific activity of thatserver. Each audited activity is referred to as an audit event. A collection of auditevent records stored in a file is referred to as an audit trail.

Each Tivoli Access Manager server maintains its own audit trail file. The TivoliAccess Manager servers include:v policy server (pdmgrd)

Chapter 9. Logging and auditing server activity 113

v authorization server (pdacld)v User-developed applications using Authorization ADK

Parameters for configuring Tivoli Access Manager server audit trail files are locatedin the [aznapi-configuration] stanza of each of the server-name.conf files.

Server server-name Configuration File

policy server pdmgrd ivmgrd.conf

authorization server pdacld ivacld.conf

Enabling and disabling auditingAudit trail recording is enabled on a server-by-server basis by setting the logauditvalue in the [aznapi-configuration] stanza of the configuration file for thespecific server.

By default auditing is disabled:[aznapi-configuration]logaudit = no

A value of yes enables 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 and is held in thespecific server’s log directory. The auditlog parameter in each server’sconfiguration file specifies the location of the audit trail file.

Server Log File Location

policy server

(pdmgrd)

UNIX:auditlog=/var/PolicyDirector/audit/pdmgrd.log

Windows:auditlog=C:\pd\audit\pdmgrd.log

authorization server

(pdacld)

UNIX:auditlog=/var/PolicyDirector/audit/pdacld.log

Windows:auditlog=C:\pd\audit\pdacld.log

Specifying audit file rollover thresholdsThe logsize parameter specifies the maximum size to which each of the audit trailfiles can grow and is initially configured with the following value (in bytes):[aznapi-configuration]logsize = 2000000

When an audit trail file reaches the specified value—known as its rolloverthreshold—the existing file is backed up to a file of the same name with anappended current date and timestamp. A new audit trail file is then started.

The various possible logsize values are interpreted as follows:


v If the logsize value is less than zero (< 0), then a new audit trail file is createdwith each invocation of the auditing process and every 24 hours from thatinstance.

v If the logsize value is equal to zero (= 0), then no rollovers are performed andthe audit trail file grows indefinitely. If an audit trail file already exists, new datais appended to it.

v If the logsize value is greater than zero (> 0), then a rollover is performed whenan audit trail file reaches the configured threshold value. If an audit trail filealready exists at startup, new data is appended to it.

Specifying the frequency for flushing audit file buffersAudit trail files are written to buffered data streams. If you are monitoring theaudit trail files in real time, you might want to alter the frequency with which theserver forces a flush of the audit trail file buffers.

By default, audit trail files are configured to be flushed every 20 seconds:[aznapi-configuration]logflush = 20

If you specify a negative value, the absolute value is used to determine when theaudit trail files are flushed.

Specifying audit eventsAudit events are categorized by the server functionality that generates them. Somefunctionality is common across Tivoli Access Manager servers while otherfunctionality is server-specific. Each type of server functionality is associated withan audit tag:

Audit tag Server functionality

authn Credential acquisition authentication auditing.

azn Authorization event auditing.

mgmt Management command auditing

You can configure each Tivoli Access Manager server to selectively capture auditevents on a category by category basis. For example, the following configurationcaptures only authentication events and disables capturing of all other events,including overriding any authorization auditing enabled in POP settings.[aznapi-configuration]auditcfg = authn

By default, when auditing is enabled for a process with no configured audit tags,all auditable events are captured.

The following table indicates the auditing events (indicated by the audit tag) thatcan be captured for each specific Tivoli Access Manager server.

Audit Tag pdmgrd pdacld authadk

authn X X X

azn X X X

mgmt X


Audit trail file formatAudit events are captured in the audit trail in a standard format using XML-styletags. Although XML is only an intermediary step to delivering a presentation viewof the data, the XML file is in ASCII format and can be read directly or passed toother external parsing engines for further analysis.

An entire audit trail does not represent a single XML document. Each audit eventwithin the file is written as an isolated XML data block. Each data block conformsto the rules of standard XML syntax.

As an audit administrator, you are expected to select and extract events accordingto your own criteria. This might include reformatting each event by applying anappropriate DTD (Document Type Definition) or schema for the analysis tool youare using. The DTD is an intermediate format that provides a description of thedata that can be captured.

A suggested DTD is as shown:<!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>

Because Tivoli Access Manager auditing uses a standard record format, not allfields are relevant to every event recorded. Generally each event captures the resultof an action that a principal attempts on a target object.

Information about the action, the principal’s credentials, the target object, and theoutcome are captured in a common format header of the audit record. Fields thatare not relevant for a particular event might contain a default value. Additionalevent-specific information can also be recorded in a free format data area at theend of the record.

Decoding the meaning of certain data values in the records might require anadvanced knowledge of the Tivoli Access Manager code and architecture.

Status attribute of the outcome fieldThe outcome field always includes a Tivoli Access Manager status code and anoutcome value. The possible outcome values include:0 = SUCCESS1 = FAILURE2 = PENDING3 = UNKNOWN

You can use the pdadmin errtext command to provide interpretation for the TivoliAccess Manager status code (412668954 in the following example).outcome status=”412668954”1/outcome

Resource attribute of the target fieldThe resource attribute of the target field represents a broad categorization of thetarget object:0 = AUTHORISATION1 = PROCESS2 = TCB3 = CREDENTIAL5 = GENERAL

Audit trail file contentsThis sections describes the contents of an audit trail file:v “Authorization audit records”v “Authentication audit records” on page 118v “Management audit records” on page 119

Authorization audit recordsAuthorization is the primary function of the Tivoli Access Manager servers.Authorization audit records can be captured when a target object in the TivoliAccess Manager authorization policy database (protected object space) has a POPattached to it that enables audit functionality.

See Chapter 4, “Protected object policies” on page 61.

You can configure auditing for a particular server by adding “azn” to the auditconfiguration list in the [aznapi-configuration] stanza of the server’sconfiguration file:[aznapi-configuration]auditcfg = azn

The following record is a sample audit record for the following event: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”“0”“0”“0”</data></event>

Authentication audit recordsAuthentication of a principal is performed externally to Tivoli Access Managerduring credential acquisition. Audit records can be captured by Tivoli AccessManager to record the success or failure of such authentication attempts.

You can configure auditing of authentication attempts by adding “authn” to theaudit configuration list in the [aznapi-configuration] stanza of the server’sconfiguration file:[aznapi-configuration]auditcfg = authn

The following is a sample authentication event logged from WebSEAL for anunauthenticated 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>


Management audit recordsThe responsibilities of the policy server include maintaining the masterauthorization policy database. This database includes the description of theprotected object space for the secure domain, ACL and POP policies, and whereACLs and POPs are attached to objects.

You can configure auditing of the policy server activity by adding “mgmt” to theaudit configuration list in the [aznapi-configuration] stanza of the policy server’sconfiguration file (ivmgrd.conf):[aznapi-configuration]auditcfg = mgmt

The following is a sample event record of the following pdadmin command: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><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 contain an event ID code thatidentifies one of the Tivoli Access Manager management (pdadmin) commands.Command arguments are listed in the data section of the event record in theirinternal format.

Note that commands that do not result in an effective change of state of thedatabase (such as list and show) are never captured.

ACL management commands

ACL_LIST 13000

ACL_GET 13001

ACL_SET_LEGACY 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

ACTION_DELETEGROUP 13014

ACL_CREATE 13020

ACL_SET 13021

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

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

SERVER_ACTION 13207

SERVER_STATUS_GET 13208

SERVER_ENABLE 13209

SERVER_DISABLE 13210

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

GROUP_LIST 13422

GROUP_LISTDN 13423

GROUP_SHOWMEMB 13424

USER_MODGSOUSER 13425

USER_SET 13426

GROUP_SET 13427

PDCMD_ID_GROUP_MODADD2 13428

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

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

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


Chapter 10. Using event logging

This chapter describes enhancements to the recording of Tivoli Access Manager logfiles. Prior versions of Tivoli Access Manager recorded events in several unrelatedlog files, usually with each log file having a different method to configure thecapture of information to disk.

The concept of the information-to-capture has now been abstracted from the actionof recording that information to a file. This loose coupling was introduced tosupport centralized collection and recording of audit trails. The new functionalityalso offers greater flexibility for the configuration and capture of other TivoliAccess Manager event data.

Tivoli Access Manager eventsApart from some messages produced when starting a program, all messagesgenerated by Tivoli Access Manager for auditing and other serviceability purposesare now created in a structured hierarchy of Tivoli Access Manager events.

The orderly categorization of events within this hierarchy allows runtimeassociations to be made between classes of events and the log agents to be used torecord those events. Additionally the concept of a log agent has been expanded toinclude recording of events to destinations other than the local file system. Theevent hierarchy is built up dynamically during program execution. While somewell-known event categories can be expected to be present when running a TivoliAccess Manager program, other categories are program specific and some might betransient.

The purpose of this chapter is to describe how you can associate log agents with apoint in the event pool hierarchy to record events. This chapter does not provide adescription of the characteristics of all possible events within the hierarchy. Fordescriptions of well-known events such as those generated for auditing, refer tothe appropriate product-specific documentation.

Generally, the event pool hierarchy is similar to the following:


A specific event category is identified by a dot-separated list of names. The firstlevel of names within the category has special significance. This top-level categoryname also might correspond to events previously associated with legacy log filesdescribed in prior releases of Tivoli Access Manager.

For example, assume the event category name is constructed as follows:domain_category.sub_category.sub_category...

Implementation note: For efficiency, an event is not generally created if there areno log agents subscribed to record events of that category. In the case that an eventis generated and there are no log agents subscribed to record it, the event isdiscarded.

Configuring event loggingIn addition to the backward-compatible method of configuring log files, you canspecify line items in the [aznapi-configuration] stanza of a program’sconfiguration (.conf) file to configure the capture of Tivoli Access Manager events.

To enable the recording of Tivoli Access Manager events using the interface, youmust associate a logging destination with a category of events in the event pool.Currently four types of destinations are supported for the capture of events:v Console log agentv File log agentv Pipe log agentv Remote log agent

The format of a log agent configuration line is as follows:

Figure 29. Event pool hierarchy


logcfg =category:{stdout|stderr|file|pipe|remote} \[[param[=value]][param[=value]]]

Options for these log agent types can be specified in any order and are generallyoptional. Valid options for each log agent type are described below. In aconfiguration entry, the option names are case insensitive and can be abbreviatedto any shortened length of the full option name that remains unique.

For example, consider the following simplified form:logcfg = category:log-agent

The category name can point to any node in the event pool hierarchy. Capture ofevents for a category is inclusive of all subcomponents in the hierarchy. That is, afoo.bar.fred event also is captured at the foo.bar category.

You can attach multiple log agents to the same category. For example, thefollowing configuration copies authorization audit events to a file and relays themto a program listening on a pipe:logcfg = audit.azn:file path=/var/PolicyDirector/log/audit.aznlogcfg = audit.azn:pipe path=/bin/analyse.exe

The following diagram depicts the relationships between steps in the loggingprocess. The top third of the diagram represents the code of a Tivoli AccessManager server. The programmer added probe points to the code where events ofspecific types might be generated. Generated events are then submitted to theserver’s event pool for possible recording through a point of capture (the sink),which defines the events category.

At runtime, a user can subscribe a log agent at any point in the event poolhierarchy to selectively record events generated at the program’s probe points. Thisis depicted in the middle band of the diagram.

One log agent that you can subscribe to for capturing events is a remote log client.This client forwards the selected events to a remote pdacld server. The bottomband of the diagram depicts this remote server. Note that the bottom band isessentially the same as the top band with the relayed events placed in the event

Chapter 10. Using event logging 127

pool at the pdacld remote probe points.

TraceEventSink

AuditEventSink

Event Pool

ApplicationSpecific Probe

Points

Standard Tivoli AccessManager Server

Remote Loggingpdacld server

Multiple OtherNetworkedLog Clients

Subscribed log agent

ConsoleFile

Adaptor

FileAdaptor

PipeAdaptor

ConsoleLog Log

File

LogFile

RemoteLog

Server

EventSink

EventPool

Subscribed LogAgents

RemoteLog

Client

OtherAdaptorEvent

Cache


Configuring the central event propagation queueEvents are passed to subscribed log agents asynchronously to the application-levelrequests that construct the events for recording. Events initially pass through acommon propagation queue before they are fanned out to the variously subscribedlog agents.

The servicing profile of this propagation queue is configurable. To configure thepropagation queue, you must specify an abridged format logcfg entry. Theshortened configuration entry uses EventPool as the category name and specifiesqueuing options without giving a log destination type. For example:logcfg = EventPool:queue_size=number,hi_water=number,flush_interval=number

Specifying the maximum number of events to queue inmemory

To control the amount of memory that can be consumed by events on thepropagation queue, you can set a limit for the maximum size the queue is allowedto grow to. If the maximum size is reached when a new event is generated, thethread attempting to queue it is blocked until space is available in the queue. Thishas the effect of throttling back performance of the event producing thread to thespeed of the logging threads, if it cannot keep up.

The default value for queue_size is 0. A zero queue size indicates that no limit isenforced on the growth of the event queue. Keep in mind that using the defaultvalue can allow the unprocessed event queue to grow to an unmanageable sizewhen events are produced at a rate faster than the subscribed log agents can clearthem.

Specifying the event queue high water markProcessing of the event queue is scheduled regularly at the configured flushinterval. It is also triggered asynchronously by the queue size reaching a highwater mark.

The default value for hi_water is 1024. If you specify a value for queue_size, butnot for hi_water value, the default hi_water is calculated as two-thirds themaximum configured queue size. If the maximum queue size is 0, the high watermark is set to a default of 100.

If the event queue high water mark is set to 1, every event queued is relayed toany subscribed log agents as soon as possible. Note that setting a low value forhi_water can have an adverse effect on overall performance.

Specifying the frequency for flushing log file buffersUse the flush_interval option to specify a limit on the time an event waits in thepropagation queue before it is forwarded to the log agents. If events are beinggenerated at a slow rate that does not trigger handling by reaching the high watermark in a timely manner, events are flushed from the propagation queue at thisfrequency.flush_interval=seconds

The flush_interval default value is 10 seconds. A flush_interval of 0 is notallowed. Specifying a value of 0 results in the queue being flushed every 600seconds.


Console loggingLogging to the console is the easiest option to configure. Simply associate anoutput destination of standard out or standard error with the category of events inthe Event Pool to capture:logcfg = category:{stdout|stderr}

Example configurations are as follows:v To capture all audit output to standard out, specify the following:

logcfg = audit:stdout

v To capture only authorization audit events to standard error, specify thefollowing:logcfg = audit.azn:stderr

Logging to the console does not itself use any queuing. The events are written tothe console as they are received from the propagation queue. Note however thatevents might be delayed in the propagation queue depending on its queue settings.

If you are using console output and running a server in the foreground fordebugging purposes, you might want to set the propagation queue settingsaccordingly. For example, set the hi_water option to a low value.

File loggingTo record events in a file, specify a log file configuration as follows:logcfg = category:file path=file_pathname, \flush_interval=seconds, \rollover_size=number, \log_id=logid, \queue_size=number, \hi_water=number, \buffer_size=number, \mode={text|binary}

A file is only opened once. If multiple configuration entries exist to selectivelycapture events at different points of the event pool hierarchy to the same file, thefile opens according to the options found in the first configuration entry processed.

After a file has been opened, further file configurations can simply use thefollowing shorthand notation to record events to the same file:logcfg = <category>:file log_id=<logid>

Because writing to file can be a slow operation relative to the tasks generatingevents, events are posted to a file log agent through a second level of queuing.This second level of event queuing is configured in a similar manner to the centralevent propagation queue, but has different default values.

Specifying the log file locationUse the path option to specify the location of a log file. There is no default valuefor the file pathname because the log_id value takes precedence. An example pathvalue for the WebSEAL audit trail file on UNIX is as follows:path=/var/pdweb/log/audit.log

The directory portion of this pathname must exist. The log file is created if it doesnot already exist.


Specifying the log file IDAn open log file is associated with a short name identifier to facilitate therecording of events from different categories to the same file.

Use the log_id option to set the log file ID explicitly; otherwise, it is given adefault value. If the path option is specified, the default value is the configuredpath name. If path is not specified, the log ID defaults to the domain component ofthe event category being captured. For example:logcfg = audit.azn:file

implieslog_id=audit.

To capture events to a common file, set the log file ID to a suitable value in a fullyoptioned file configuration. Subsequently, use the shorthand configuration variantto capture events from additional categories as shown:logcfg = audit.azn:file path=/opt/PolicyDirector/log/audit.log, \rollover_size=-1,flush=20,log_id=audit

logcfg = audit.authn:file log_id=audit

Because of the default rules, this configuration is also equivalent to the followingspecification:logcfg = audit.azn:file \path=/opt/PolicyDirector/log/audit.log,rollover_size=-1

logcfg = audit.authn:file

If you construct a configuration where the log_id value does not match any openlog file, no events are captured. For example, the following configuration does notrecord any events because the configuration line that initializes the log file hasbeen commented out:#logcfg = audit.azn:file path=/tmp/azn.log,log_id=aznlogcfg = audit.authn:file log_id=azn

Specifying the maximum log file sizeUse the rollover_size option to specify the maximum size to which a log file cangrow. This option has the following default value (in bytes):rollover_size=2000000

When the size of a log file reaches the specified value, known as its rolloverthreshold, the existing file is backed up to a file of the same name with anappended current date and time stamp. A new log file is then started.

The various possible rollover_size values are interpreted as follows:v If the rollover_size value is less than zero (< 0), a new log file is created with

each invocation of the process and every 24 hours from that instance.v If the rollover_size value is equal to zero (= 0), no rollovers are performed and

the log file grows indefinitely. If a log file already exists, new data is appendedto it.

v If the rollover_size value is greater than zero (> 0), a rollover is performed whena log file reaches the configured threshold value. If a log file already exists atstartup, new data is appended to it.


Specifying the maximum buffer sizeTo reduce memory fragmentation and improve the performance of writing to a file,rather than queuing many small events individually to the file log agent, eventscan be buffered into blocks of a nominated size before queuing for writing. Thebuffer_size option specifies the maximum size message that the program attemptsto construct by combining smaller events into a large buffer.

Buffers consist of only an integral number of events; events are not split acrossbuffers. If any individual event exceeds that maximum configured size, the largeevent is recorded in a buffer of its own, exceeding the configured value.buffer_size=number_of_bytes

The default buffer size for logging to a file is 0 bytes. This value prevents bufferingand each event is handled individually.

If a value is specified for the buffer_size, events are packed into buffers of thatsize before queuing to the file log agent.

For example, if the buffer_size value is set to 2 KB and events are assumed to beabout 256 bytes, around 10 are packed into each buffer written to the file. Thisreduces the number of disk I/Os made while logging to 10 percent of theequivalent non buffering case.

Note that a default queue size of 200 with a buffer_size of 2 KB also consumesaround 10 times the memory of a default configuration that did no buffering(assuming an event size of around 200 bytes). This is because the maximum queuesize value has not been changed, but the size of events being queued has increasedtenfold.

Specifying the maximum number of events to queue inmemory

There is a delay between events being placed on the queue and the file log agentremoving them. The queue_size option specifies the maximum size to which thequeue is allowed to grow. If the maximum size is reached when a new event isready to be placed on the queue, the requesting thread is blocked until space isavailable in the queue. This has the effect of throttling back performance of theevent propagation thread to the speed of the file logging thread, if it cannot keepup.

The default value for queue_size is 0. A zero queue size means that no limit isenforced on the growth of the unprocessed event queue. Correspondingly, theevent propagation thread is not constrained by the speed of the logging thread.Keep in mind that using the default can result in the unrecorded event queuegrowing to an unmanageable size, if events are being generated faster than theycan be recorded to file.

Specifying the event queue high water markProcessing of the event queue is scheduled regularly at the configured flushinterval. It also is triggered asynchronously by the queue size reaching a highwater mark on the event queue.

The default value for hi_water is two-thirds of the maximum configured queuesize. If the maximum queue size is zero, the high water mark is set to a default of100.


The transaction rates and the values of these options determine the maximumamount of memory that is consumed by enabling event logging to file.

If the event queue high water mark is set to 1, every event queued is relayed tothe log agent as soon as possible. This setting is not optimal, although you mightwant to use it if you want to ensure events get to disk as fast as possible, at theexpense of overall performance.

Specifying the frequency for flushing log file buffersThe flush_interval option is a multi-use option.

The logging to file flush_interval option has the following default value inseconds.flush_interval=20

A flush interval of 0 is not allowed. Specifying a value of 0 results in the value 600being used.

Log files are written to buffered data streams. To ensure stream buffers are flushedto disk regularly, the frequency with which the server asynchronously forces aflush of the file stream to disk is configurable using this option.

If you specify a negative value, the absolute value is used as the asynchronousflush frequency, but a stream flush is also forced synchronously after every recordis written.

If events are being consolidated into large buffers by specifying a buffer_sizeoption, the flush_interval parameter also might affect the size of buffer written. Ifthere is a partially filled buffer in memory when a flush is scheduled, that buffer isalso queued for writing before it completes the buffer fill.

Lastly, the event queue is triggered for processing at the flush interval rate. Thisprevents events waiting to be processed for longer than the scheduled flush timewhen the queue high water mark is not reached between scheduled flushes.

Specifying the file modeUse the mode option to open a file in either text or binary mode. For example:mode={text|binary}

Text mode is deprecated on UNIX platforms and has no effect. On WIN32platforms, opening a file in text mode enables end-of-line character translations inthe log file. Binary mode on a Windows platform writes the log file in a UNIXcompatible format.

Pipe loggingUse the pipe option to write output to the standard input of another program. Forexample:logcfg=<category>:pipe path=<program_pathname>, \queue_size=<number>, \hi_water=<number>, \flush_interval=<number>

The named program must exist and be executable. The administrator is responsiblefor ensuring the security of the program that is to be run.


Each occurrence of a pipe agent in the configuration file invokes a new copy of thepipe program. Unlike logging to file, piped events are not multiplexed fromdifferent category capture points to a single copy of the program.

Specifying the program to runUse the path option to specify the location of the program, which receives the logoutput on standard input. For example:path=/opt/risk_analyser/bin/my_log_watcher

Note that there is no default value for the path name.

Specifying the event queuing profileConfigure the pipe logging event queue management in the same way that youconfigure logging to file. The queue_size, hi_water, and flush_interval optionshave similar meaning to the options described for file logging.

Remote loggingUse the remote option to send events to a remote server for recording. Forexample:logcfg = category:remote \buffer_size=size, \compress={yes|no}, \error_retry=timeout, \path=name, \flush_interval=number, \rebind_retry=timeout, \server=hostname, \port=number, \dn=identity, \queue_size=number,hi_water=number

Requests to log an event remotely are accepted on a best effort basis only. If theremote server is not available, captured events are cached locally and relayed at alater date, if and when the remote server becomes available.

Only one remote logging connection is established to a remote server. If multipleconfiguration entries are made to selectively capture events at different points ofthe event pool hierarchy to the same remote server, the remote connection isestablished according to the options of the first remote configuration entryprocessed. Multiple remote connections can be configured to log to differentremote servers.

Events received at the remote server are placed in the event pool of that server in adifferent location from where they were originally captured on the client system.All events entering a host through the remote logging service are placed in acategory constructed in the following manner:remote.client-category-domain.hostname.program

For example, all audit events logged remotely from program pdmgrd on hostamazon appear on the remote log server under pool remote.audit.amazon.pdmgrd.This allows for the remote server to selectively record events in a variety ofdestinations using standard configurations. For example, all audit events from hostamazon can be recorded centrally on host timelord by a configuration such as:


On host amazon to relay events remotely:logcfg = audit:remote buffer=2000,compress=y,error=2, \path=/opt/PolicyDirector/log/remote.cache,rebind=600,server=timelord,port=7136

On host timelord to record events to file:logcfg = remote.audit:file path=consolidated_audit.log

logcfg = remote.audit.amazon.pdmgrd:file path=amazon_pdmgrd_audit.log

Specifying the maximum buffer sizeTo reduce network traffic, events are buffered into blocks of the nominated sizebefore relaying to the remote server. The buffer_size option specifies the maximumsize message that the local program attempts to construct by combining smallerevents into a large buffer. Buffers consist only of an integral number of events;events are not split across buffers. If any individual event exceeds that maximumconfigured size, the large event is sent in a buffer of its own, exceeding theconfigured value.buffer_size=number_of_bytes

The default buffer size is 1024 bytes.

Specifying the frequency for flushing the consolidation bufferIf events are being consolidated into very large buffers and there is not muchlogging activity, events can sit in memory for a long time before being forwardedto the remote server or being written to the cache file. The flush_interval optionlimits the time a process waits to fill a consolidation buffer. For example:flush_interval=seconds

The default flush interval is 20 seconds. A flush interval of 0 is not allowed.Specifying a value of 0 results in the buffer being flushed every 600 seconds.

Specifying the queue sizesThe queue_size and hi_water values for a remote logging connection are similar tothose specified for logging to a file. The default values are as follows:queue_size=0hi_water=100

Specifying compression of messagesTivoli Access Manager events are principally text messages. To reduce networktraffic use the compress option to compress buffers prior to transmission andexpand on reception. For example:compress={yes|no}

The default compress value is no.

Specifying the error retry timeoutIf a send to a remote service fails, it is retried after a wait of the error retry timeoutin seconds. If the retry also fails, the link is marked down and this event andfuture events are saved in the local event cache file until the remote service isrebound.error=seconds

The default error retry timeout is 2 seconds.


Specifying the cache file locationThe path option specifies the location of a cache file on the local host. The cachefile name defaults to ./server.cache, where server is the name of the remote serverbeing logged to.

If the running process cannot establish communication with the remote server, orthe link fails during operation, event recording switches to storing events in thespecified file until the server again becomes available. When the server is available,events are drained from the disk cache and relayed to the remote server.

For example, suppose the path value for pdmgrd on UNIX is as follows:path=/var/PolicyDirector/log/pdmgrd_remote.cache

The directory portion of this pathname must exist. The log file is created if it doesnot already exist. The size of this file is not bound and it does not have anyrollover capability. If a remote server is not accessible for sufficient time, you couldrun out of disk space.

Specifying the rebind retry timeoutIf the remote server is unavailable, the log agent attempts to rebind to the server atthis frequency in number of seconds (default 300).rebind_interval=60

Specifying the remote serverThe remote logging services are offered by the pdacld program. Remote loggingpiggy-backs on the certificates set up for the authorization service as initialized bya call to azn_initialize(). This option nominates which hosts pdacld process isbound to for event recording.server=hostname

Specifying the remote server portUse the port option to specify the port that the remote pdacld listens on for remotelogging requests.port=number

The default value is 7136.

Specifying the remote server distinguished nameTo establish mutual authentication of the remote server, a distinguished name (DN)must be configured that can be checked against the name returned in the remoteservers certificate. The default value for the DN is a null string.

A DN must be specified as a string enclosed by double quotation marks. Using thedefault value or explicitly specifying an empty string enables the logging client topromiscuously establish a remote server connection. Specifying a value for the DNlimits successful connection to a specific server:dn="cn=ivacld/timelord.testnet.tivoli.com,o=policy director,c=us"


Locating event categoriesThe name of each event category is written to a trace event as it is instantiated. Toview trace records, enable trace during start up by adding the following line to therouting file:*:*.9:TEXTFILE:pd_dir/log/trace_%ld.log

Monitoring log queue performanceThe queuing profiles configured for the main propagation queue—and each file,remote, and pipe log agent—can be monitored using the statistics interface.

Each queue is implemented by instantiating an EventQueue object that registersitself with the statistics subsystem using a category name constructed from thelogging agent type and the string, pd.log.

The statistics of an event queue can be interrogated by using pdadmin server taskcommands. To establish what queues are implemented on a server, issue the servertask server_name stats list command. A report similar to the following is returned:pdadmin> server task ivacld-barra.surf.ap.tivoli.com stats listpd.ras.stats.monitorpd.log.EventPool.queue // Main event propagation queuepd.log.file.audit // Audit log queuepdadmin

To examine the statistics for a queue, enter the stats get command as follows:pdadmin> server task ivacld-barra.surf.ap.tivoli.com \

stats get pd.log.EventPool.queue

A report similar to the following is displayed:dispatcher wakes on timeout(20) : 3617dispatcher wakes by notify : 0

notifies above highwater (100) : 0notifies below highwater : 0spurious notifies : 0

total events processed : 24average number of events handled per activation : 1greatest number of events handled per activation : 7blocks in queue requests : 0pdadmin>

The queue flush frequency is listed in parentheses after the word, timeout. Thequeue’s high water setting is listed in parentheses after the word, highwater.

The settings chosen for the various queue configuration options should attempt tobalance the maximum amount of memory consumed between queue activationswith the rate at which a particular log agent can consume events.

Optimally, you should set the queue high water mark such that the number ofevents processed during a queue activation fills a processing time slice. This settingavoids unnecessary thread context switching. Note however, that simply settingthese options to high values is unlikely to be productive because event logprocessing must be done at some point and cannot be deferred indefinitely.Consuming large amounts of memory also has its own drawbacks.


Appendix A. Server configuration reference

Note: Do not change the attribute names in the configuration files. Changing anattribute name might cause unpredictable server configuration results.

activedir.conf referenceactivedir.conf configuration file

Stanzas:v [uraf-ad]


[uraf-ad] stanza

enabled

Multi-domain Configured (true value) or not configured(false value) to multi-domain Active Directory.

HostName Active Directory DNS host name.

domain Active Directory root domain name.

useEncryption Enable (true value) or disable (false value)encryption communication to Active Directory.

bind-id Tivoli Access Manager configuration login ID.

bind-pwd Tivoli Access Manager configuration loginpassword.

dnforpd Distinguished Name in Active Directory tostore Tivoli Access Manager data.

domino.conf referencedomino.conf configuration file

Stanzas:v [uraf-domino]


[uraf-domino] stanza

enabled

server Domino™ server name.

HostName Domino server TCP/IP host name.

LDAPPort Domino server LDAP port.

UseSSL Indicates whether or not to use SSL.

KeyFile SSL key file.

KeyFile_PW SSL key file password.

KeyFile_DN SSL key file private key name.

password Notes® client password for access to Dominodatabases.



NAB Domino Name & Address Book database. Thenames.nsf database cannot be changed.

PDM Tivoli Access Manager meta-data database.

ivacld.conf referenceivacld.conf configuration file for the authorization server (pdacld).

Stanzas:v [ivacld]

v [ldap]

v [uraf-ad]

v [uraf-domino]

v [ssl]

v [manager]

v [authentication-mechanisms]

v [aznapi-configuration]

v [aznapi-entitlement-services]

v [aznapi-pac-services]

v [aznapi-cred-modification-services]

v [aznapi-admin-services]


[ivacld] stanza

tcp-req-port TCP listening port for incoming requests (0 =disable).

pid-file Location of PID file.

log-file Location of log file.

unix-user UNIX user account for this server.

unix-group UNIX group account for this server.

permit-unauth-remote-caller Specifies whether authorization API clientsshould (false value) or should not (true value)be authorized by the authorization serverbefore their requests are processed. Note:Setting this to true exposes the policy databasein the domain for all clients to read.

[ldap] stanza

enabled Enable (yes value) and disable (no value)LDAP user registry support.

host LDAP server host name.

port The IP port used when binding to the LDAPserver.

bind-dn The LDAP user DN used when binding to theLDAP server.

bind-pwd The LDAP user password.



cache-enabled Enable (true value) and disable (false value)LDAP client-side caching to improveperformance for similar LDAP queries.

prefer-readwrite-server Optional. Enable and disable the choice for theclient to query the read/write LDAP serverbefore querying any replica read-only serversconfigured in the domain.

ssl-enabled Optional. Enable (yes value) and disable (novalue) SSL communication with the LDAPserver.

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.

max-search-size Maximum search buffer size returned from theLDAP server in entries.

ssl-port SSL port to listen on for LDAP communication.

auth-using-compare Optional. Choose whether ldap_compare()(true value) is used instead of the ldap_bind()(false value) call to authenticate LDAP users.This option changes the method used by theseaznAPI calls: – azn_util_client_authenticate()and – azn_util_password_authenticate().

ldap-replica Define the LDAP user registry replicas in thedomain. Syntax: ldap-server = ldap_server, port,type, preference

where:

v ldap_server is the network name of the server

v port is the port of the LDAP server

v type is one of: readonly and readwrite

v preference is a number from 1 to 10 (10 is thehighest preference)

[uraf-ad] stanza

ad-server-config Location of Active Directory registryconfiguration file.

bind-id Server identity for bind.

bind-pwd Server password for bind.


domino-server-config Location of Domino registry configuration file.



[ssl] stanza

ssl-keyfile Location of the SSL keyfile.

ssl-keyfile-stash Location of SSL password stash file.

ssl-keyfile-label Label of key to use other than the default.

ssl-v3-timeout Session timeout for SSL v3 connections (range:1-86400). Example: ssl-v3-timeout = 7200.

Appendix A. Server configuration reference 141


ssl-listening-port TCP port to listen on for incoming policyserver requests (0 = disable).

ssl-io-inactivity-timeout The duration (in seconds) that an SSLconnection waits for a response before timingout. Value must be equal to or greater than 0(0= no timeout).

ssl-maximum-worker-threads Maximum number of threads created by theserver to handle incoming requests. Value mustbe greater than or equal to 1 (system resourcedependant). Example: ssl-maximum-worker-threads = 50

ssl-pwd-life SSL password lifetime (in days).

ssl-auto-refresh Enable (yes value) and disable (no value)automatic refresh of the SSL certificate and thekey database file password. If enabled, thecertificate and password are regenerated wheneither is near expiration.

ssl-authn-type Authentication type. Example: ssl-authn-type= certificate.

[manager] stanza

manager-host Host name of the policy server.

master-port TCP port on which the server is listening forrequests. Example: master-port = 7135

[authentication-mechanisms] stanza

passwd-uraf Location of library to use for authentication.

cert-uraf Location of library to use for authentication.

passwd-ldap Location of library to use for authentication.

cert-ldap Location of library to use for authentication.

[aznapi-configuration] stanza

logsize Log file rollover threshold (in bytes) for auditlogs (0 = no rollover, any negative number =daily rollovers). Example: logsize = 2000000.

logflush Duration (in seconds) of the flushing of log filebuffers for audit logs (default = 20, maximum= 6 hours). Example: logflush = 20.

logaudit Enable (no value) and disable (yes value)auditing.

auditlog Location of the local client’s audit trail file.

auditcfg = azn Capture authorization events.

auditcfg = authn Capture authentication events.

db-file The location of the pdacld database cache file.

cache-refresh-interval The interval between checks for updates to themaster authorization server. Values can bedisable, default or a time in seconds. Note:the local cache is rebuilt only if an update isdetected.



listen-flags Enable (enable value) and disable (disablevalue) the receiving of policy cache updatenotifications.

[aznapi-entitlement-services] stanza

Defines authorization API services.

[aznapi-cred-modification-services] stanza

AZN_MOD_SVC_RAD_2AB A credential modification service that allowsgroups to be dynamically appended to anexisting credential. This action can give theowner of the credential additionalauthorization capability.

[aznapi-admin-services] stanza

AZN_ADMIN_SVC_TRACE Enable and disable (using pdadmin) traceadministration for an authorization APIapplication.

ivmgrd.conf referenceivmgrd.conf configuration file for the policy server (pdmgrd).

Stanzas:v [ivmgrd]

v [ldap]

v [uraf-ad]

v [uraf-domino]

v [ssl]

v [authentication-mechanisms]

v [aznapi-configuration]

v [aznapi-entitlement-services]

v [aznapi-pac-services]

v [aznapi-cred-modification-services]

v [aznapi-external-authzn-services]

v [delegated-admin]


[ivmgrd] stanza

unix-user UNIX user account for this server.

unix-group UNIX group account for this server.

database-path Location of master authorization database.

tcp-req-port TCP listening port for incoming requests (0=disable).Example: tcp-req-port = 7135.

max-notifier-threads Maximum number of event notifier threads. Example:max-notifier-threads = 10.

auto-database-update-notify Enable (yes value) automatic or manual (no value)update notification for authorization database replicas(default = no).



notifier-wait-time Time (in seconds) the authorization policy database isidle before notification is sent to replicas (default = 15).

pid-file Location of PID file.

log-file Location of log file.

ca-cert-download-enabled Allow (yes value) clients to download the root CAcertificate.

[ldap] stanza

ldap-server-config Location of the ldap.conf configuration file.

prefer-readwrite-server Enable (yes value) and disable (no value) the choice forthe client to query the read/write LDAP server beforequerying any replica read-only servers configured inthe domain.

bind-dn The LDAP user DN used when binding to the LDAPserver.

bind-pwd The LDAP user password.

ssl-enabled Enable (yes value) and disable (no value) SSLcommunication with the LDAP server.

ssl-keyfile Location of SSL key file used to handle certificates usedin 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() (yes value) is usedinstead of the ldap_bind() (no value) call toauthenticate LDAP users.

[uraf-ad] stanza

ad-server-config Location of Active Directory registry configuration file.




domino-server-config Location of Domino registry configuration file.



[ssl] stanza

ssl-keyfile Location of the SSL key file.

ssl-keyfile-stash Location of SSL password stash file.

ssl-keyfile-label Label of key to use other than the default.

ssl-v3-timeout Session timeout for SSL v3 connections (range: 1-86400).Example: ssl-v3-timeout = 7200.

ssl-listening-port TCP port to listen on for incoming requests (0 =disable).

ssl-io-inactivity-timeout The duration (in seconds) that an SSL connection waitsfor a response before timing out. Value must be equalto or greater than 0 (0= no timeout).



ssl-maximum-worker-threads Maximum number of threads created by the server tohandle incoming requests. Value must be greater thanor equal to 1 (system resource dependant). Example:ssl-maximum-worker-threads = 50.


ssl-cert-life SSL certificate lifetime (in days).

ssl-auto-refresh Enable (yes value) and disable (no value) automaticrefresh of the SSL certificate and the key database filepassword. If enabled, the certificate and password areregenerated when either is near expiration.

[authentication-mechanisms] stanza

passwd-uraf Location of library to use for authentication.

cert-uraf Location of library to use for authentication.

passwd-ldap Location of library to use for authentication.

cert-ldap Location of library to use for authentication.

[aznapi-configuration] stanza

logsize Log file rollover threshold (in bytes) for audit logs (0 =no rollover, any negative number = daily rollovers).Example: logsize = 2000000.

logflush Duration (in seconds) of the flushing of log file buffersfor audit logs (default = 20, maximum = 6 hours).Example: logflush = 20.

logaudit Enable (no value) and disable (yes value) auditing.

auditlog Location of audit file.

auditcfg = azn Disable or enable component audit records by addingor removing this definition.

auditcfg = authn Disable or enable component audit records by addingor removing this definition.

auditcfg = mgmt Disable or enable component audit records by addingor removing this definition.

[aznapi-entitlement-services] stanza

[aznapi-pac-services] stanza

[aznapi-cred-modification-services] stanza

[aznapi-external-authzn-services] stanza

[delegated-admin] stanza

authorize-group-list Enable (yes value) and disable (no value) authorizationchecks on the group list and group list-dn commands.

ldap.conf referenceStanzas:v [ldap]



[ldap] stanza

enabled Tivoli Access Manager 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 Tivoli Access Manager limit for an LDAP clientsearch of database items - such as a request for theWeb Portal Manager to list users from the LDAPdatabase.

replica Replica LDAP server entry. For each replica server adda line of the form: replica =ldap_server,port,type,preference

where:

v ldap_server is the network name of the LDAP server

v port is the port to listen on (389 or 636)

v type is one of readonly or readwrite

v preference is a number between 1 and 10Note: The master readwrite LDAP server enteredwith host = defaults to a preference of 5. The serverwith the highest preference value is chosen forLDAP connections. If this server fails, then serverswith the next highest value is used. If servers havethe same preference value, then load balancingoccurs between all of them.

pd.conf referencepd.conf configuration file

Stanzas:v [pdrte]

v [ssl]

v [manager]

v [ldap-ext-cred-tags]


[pdrte] stanza

configured Indicates whether the Tivoli Access Managerruntime package has been configured.

user-reg-type User registry type. Currently, only LDAP issupported.

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 policy server (pdmgrd) at systemboot.Note: For UNIX systems only.

boot-start-ivacld Start the authorization server (pdacld) atsystem boot.Note: For UNIX systems only.

[ssl] stanza

ssl-keyfile Location of the local system of the SSL key file.

ssl-keyfile-stash Location of the SSL password stash file.

ssl-keyfile-label Name of certificate to use other than thedefault.

ssl-v3-timeout Session timeout for SSL v3 connections (range:1-86400). Example: ssl-v3-timeout = 7200.


ssl-io-inactivity-timeout The duration (in seconds) that an SSLconnection waits for a response before timingout. Value must be equal to or greater than 0(0= no timeout).

ssl-auto-refresh Enable (yes value) and disable (no value)automatic refresh of the SSL certificate and thekey database file password. If enabled, thecertificate and password are regenerated wheneither is near expiration.

[manager] stanza

master-host Host name of the policy server.

master-port TCP port number on which the server islistening for requests.

[ldap-ext-cred-tags] stanza

credential-field-name =ldap-inetOrgPerson-field

Mechanism to add extended attributes to theTivoli Access Manager credential from existingfields in the inetOrgPerson LDAP object class.


Appendix B. User registry differences

The following user registry differences are known to exist in this version of IBMTivoli Access Managerv Leading and trailing blanks in user names and group names are ignored when

using LDAP or Microsoft Active Directory as the user registry in an TivoliAccess Manager secure domain. However, when using a Lotus Domino server asa user registry, leading and trailing blanks are significant. To ensure thatprocessing is consistent regardless of what user registry is being used, defineusers and groups in the user registry without leading or trailing blanks in theirnames.

v The forward slash character (/) should be avoided in user and group namesdefined using distinguished name strings. Although, users and groups can becreated with names using a distinguished name string containing a forwardslash character, subsequent operations on the object might fail as some directoryfunctions interpret the forward slash character as a separator between the objectname and the host name. To avoid the problem, do not use a forward slashcharacter to define the user.

v When using a Lotus Domino user registry, the pdadmin command lineinterpretation differs from the LDAP-centric format that is displayed when youenter a command without any parameters. The different interpretations of thepdadmin user and group management commands when using a Dominoregistry are shown in Table 2 and Table 3 on page 150.

Table 2. User management commands

Command Description

user create [–gsouser] username dn cn sn password

Creates a Tivoli Access Manager user account in the Dominoregistry.

The –gsouser argument has no effect when Tivoli Access Manager isconfigured to use a Domino registry.

The username argument is the name for the user being created.

The dn argument is the Domino registry’s hierarchical nameassigned to the user being created in the Domino Name andAddress Book (NAB) database. Example:

Diana Lucas/Austin/IBM

The cn argument is the first name assigned to the user beingcreated. Example:

Diana

The sn argument is the last name of the user being created.Example:

Lucas


Table 2. User management commands (continued)

The password argument is the Internet password you set for thisnew user in the Domino NAB database. Passwords must adhere tothe password policies set by the Tivoli Access Manageradministrator. Example:

mypasswd

Example (entered as one line)

pdadmin> user create dlucas "Diana Lucas/Austin/IBM" Diana Lucas mypasswd

The created user account is initially set as invalid. If you want toenable the user’s account, you must manually enable this user bymodifying the user information. To change the information, youmust set the account-valid flag to Yes.

To add a description about a user, you must use the modify usercommand to change the user account information.

user import [–gsouser] username dn

Allows an existing Domino user whose person document exists inthe Domino registry’s NAB database to be updated with TivoliAccess Manager information so the user can participate in thesecure domain.

The username argument is the name for the existing Domino userbeing imported.

The –gsouser argument has no effect when Tivoli Access Manager isconfigured to use a Domino registry.

The dn argument is the Domino registry’s hierarchical nameassigned to the user being imported from the Domino registry’sNAB database. Example:

Diana Lucas/Austin/IBM

Example:

pdadmin> user import dlucas "Diana Lucas/Austin/IBM"

Table 3. Group management commands

Command Description

group create groupname dn cn

Creates a Tivoli Access Manager user account in the Dominoregistry.

The groupname argument is the name for the group being created.

The dn argument is the Domino registry’s hierarchical nameassigned to the group being created. Example:

CreditDept/Austin/IBM

The cn argument does not have any effect when Tivoli AccessManager is configured for a Domino registry. However, due to theexisting interface requirement, you must enter some string for thecn argument. Example:

pdadmin> group create creditdept "CreditDept/Austin/IBM" anystring


Table 3. Group management commands (continued)

group import groupname dn

Create a new Tivoli Access Manager group by importinginformation from an existing Domino registry group. The groupmust already exist in the Domino registry’s NAB database beforeyou can import the information and create a new Tivoli AccessManager group.

The groupname argument is the name of the existing Dominogroup being imported.

The dn argument is the Domino registry’s hierarchical nameassigned to the existing Domino group being created. Example:

EngineeringDept/Austin/IBM

Example:

pdadmin> group import engineeringdept"EngineeringDept/Austin/IBM"

v When using a multi-domain Microsoft Active Directory user registry, multipleusers and groups can be defined with the same short name as long as they arelocated in different Active Directory domains. To refer to a specific user orgroup, use the full name of the user or group, including the @AD_domain_namesuffix, to ensure that you are getting the correct results. The practice of usinguser and group names, followed by @AD_domain_name suffix, needs to bemaintained across all Tivoli Access Manager supported operations. When usinga single domain Active Directory user registry, do not specify the@AD_domain_name suffix for user or groups.

v When using iPlanet Version 5.0 as the user registry, a user that is created, addedto a group, and then deleted from the user registry retains its groupmembership. If a user with the same name is created at some later time, the newuser automatically inherits the old group membership and might be giveninappropriate permissions. To avoid this situation, remove the user from allgroups before deleting the user. This problem does not occur when using theother supported user registries.

v Attempting to add a duplicate user to a group produces different results basedon the user registry being used. Table 4 outlines the differences.

Table 4. User registry differences when adding a duplicate user to a group

Operation LDAP Lotus Domino server Microsoft ActiveDirectory

Add one user andthat user is duplicate

Error No error Error

Add multiple users,first user is duplicate

Error for all users No error Error for all users

Add multiple users, auser other than thefirst is a duplicate

Error for all users No error Partial completionmessage

v Attempting to remove a user from a group who is not a member of the groupproduces different results based on the user registry being used. Table 5 onpage 152 outlines the differences.

Appendix B. User registry differences 151

Table 5. User registry differences when removing a user from a group who is not a memberof the group

Operation LDAP Lotus Domino server Microsoft ActiveDirectory

Remove one user,user is not in thegroup

Error Error Error

Remove multipleusers, first user notin the group

Error for all users Error Error for all users

Remove multipleusers, a user otherthan the first is not inthe group

Error for all users Partial completionmessage

Partial completionmessage

v The maximum lengths of various names associated with a user vary dependingon the user registry being used. See Table 6 for a comparison of the maximumlengths allowed and the recommended maximum length to use to ensurecompatibility with all the user registries supported by Tivoli Access Manager.

Table 6. Maximum lengths for names based on user registry

Maximumlength of:

LDAP Microsoft ActiveDirectory

Lotus Dominoserver

Recommendedmaximum value

First name(LDAP CN)

256 64 960 64

Middle name 128 64 65535 64

Last name 128 64 960 64

Registry UID(LDAP DN)

1024 2048 255 This value isuser

registry-specificand must be

changed whenchanging user

registries.

Tivoli AccessManager useridentity

256 64 200 - 4 -length_of_

domain_name

This value isuser

registry-specificand must be

changed whenchanging user

registries.

v Users created in a Lotus Domino server or Microsoft Active Directory userregistry are automatically given the capability to own single signon credentialsand this capability cannot be removed. When using an LDAP user registry, thiscapability must be explicitly granted to a user and subsequently can beremoved.

v When the Tivoli Access Manager policy server is using either Microsoft ActiveDirectory or a Lotus Domino server as its user registry, existing TivoliSecureWay Policy Director, Version 3.8 clients are not able to connect to thepolicy server. Either use a different user registry or upgrade the clients to TivoliAccess Manager.


Appendix C. Notices

This information was developed for products and services offered in the U.S.A.IBM may not offer the products, services, or features discussed in this document inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user’s responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not give youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chome, Minato-kuTokyo 106, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION ″AS IS″ WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express orimplied warranties in certain transactions, therefore, this statement may not applyto you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Websites. The materials at those Web sites are not part of the materials for this IBMproduct and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way itbelieves appropriate without incurring any obligation to you.


Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758U.S.A.

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

The licensed program described in this document and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

All statements regarding IBM’s future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrates programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment toIBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operatingplatform for which the sample programs are written. These examples have notbeen thoroughly tested under all conditions. IBM, therefore, cannot guarantee orimply reliability, serviceability, or function of these programs. You may copy,modify, and distribute these sample programs in any form without payment toIBM for the purposes of developing, using, marketing, or distributing applicationprograms conforming to IBM’s application programming interfaces.

Each copy or any portion of these sample programs or any derivative work, mustinclude a copyright notice as follows:

© (your company name) (year). Portions of this code are derived from IBM Corp.Sample Programs. © Copyright IBM Corp. _enter the year or years_. All rightsreserved.


If you are viewing this information softcopy, the photographs and colorillustrations may not appear.

TrademarksThe following terms are trademarks or registered trademarks of InternationalBusiness Machines Corporation in the United States, other countries, or both:

AIXDB2IBMIBM logoOS/390SecureWayTivoliTivoli logoUniversal DatabaseWebSpherezSeriesz/OS

Lotus and Domino are trademarks of International Business Machines Corporationand Lotus Development Corporation in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States and other countries.

Microsoft and Windows are trademarks of Microsoft Corporation in the UnitedStates, other countries, or both.

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

Other company, product, or service names may be trademarks or service marks ofothers.

Appendix C. Notices 155

Glossary

Aaccess control. In computer security, the process ofensuring that the resources of a computer system canbe accessed only by authorized users in authorizedways.

access control groups. Groups to be used for accesscontrol. Each group contains a multivalued attributeconsisting of member distinguished names. Accesscontrol groups have an object class of AccessGroup.

access control list. (1) (2) In computer security, a listthat is associated with an object that identifies all thesubjects that can access the object and their accessrights. For example, an access control list is a list that isassociated with a file that identifies the users who canaccess the file and identifies the users’ access rights tothat file.

access permission. The access privilege that applies tothe entire object. or permissions that apply to attributeaccess classes.

action. An access control list (ACL) permissionattribute.

ACL. See access control list.

administration service. An authorization API runtimeplug-in that can be used to perform administrationrequests on an Access Manager resource managerapplication. The admin service will respond to remoterequests from the pdadmin command to perform taskssuch as listing the objects under a particular node inthe protected object tree. Customers may develop theseservices using the Authorization ADK.

attribute list. In Tivoli Access Manager, a linked listthat contains extended information that is used to makeauthorization decisions. Attribute lists consist of a set ofkeyword = value pairs.

authentication. (1) In computer security, verification ofthe identity of a user or the user’s eligibility to accessan object. (2) In computer security, verification that amessage has not been altered or corrupted. (3) Incomputer security, a process that is used to verify theuser of an information system or of protected resources.See also multi-factor authentication, network-basedauthentication, andstep-up authentication.

authorization. (1) In computer security, the rightgranted to a user to communicate with or make use ofa computer system. (2) The process of granting a usereither complete or restricted access to an object,resource, or function.

authorization service plug-in. A dynamically loadablelibrary (DLL or shared library) that can be loaded bythe Access Manager authorization API runtime client atinitialization time in order to perform operations thatextend a service interface within the Authorization API.The service interfaces that are currently availableinclude Administration, External Authorization,Credentials modification, Entitlements and PACmanipulation interfaces. Customers may develop theseservices using the Authorization ADK.

BBA. See basic authentication.

basic authentication. A method of authentication thatrequires the user to enter a valid user name andpassword before access to a secure online resource isgranted.

bind. To relate an identifier to another object in aprogram; for example, to relate an identifier to a value,an address or another identifier, or to associate formalparameters and actual parameters.

blade. A component that provides application-specificservices and components.

business entitlement. The supplemental attributes ofa user credential that describes the fine-grainedconditions that can be used in the authorizationrequests for resources.

CCA. See certificate authority.

CDAS. See Cross Domain Authentication Service.

CDMF. See Cross Domain Mapping Framework.

certificate. In computer security, a digital documentthat binds a public key to the identity of the certificateowner, thereby enabling the certificate owner to beauthenticated. A certificate is issued by a certificateauthority.

certificate authority (CA). In e-commerce, anorganization that issues certificates. The certificateauthority authenticates the certificate owner’s identityand the services that the owner is authorized to use,issues new certificates, renews existing certificates, andrevokes certificates belonging to users who are nolonger authorized to use them.

CGI. See common gateway interface.


cipher. Encrypted data that is unreadable until it hasbeen converted into plain data (decrypted) with a key.

common gateway interface (CGI). A computerprogram that runs on a Web server and uses theCommon Gateway Interface (CGI) to perform tasks thatare not usually done by a Web server (for example,database access and form processing). A CGI script is aCGI program that is written in a scripting languagesuch as Perl.

configuration. (1) The manner in which the hardwareand software of an information processing system areorganized and interconnected. (2) The devices andprograms that make up a system, subsystem, ornetwork.

connection. (1) In data communication, an associationestablished between functional units for conveyinginformation. (2) In TCP/IP, the path between twoprotocol applications that provides reliable data streamdelivery service. In the Internet, a connection extendsfrom a TCP application on one system to a TCPapplication on another system. (3) In systemcommunications, a line over which data can be passedbetween two systems or between a system and adevice.

container object. A structural designation thatorganizes the object space into distinct functionalregions.

cookie. Information that a server stores on a clientmachine and accesses during subsequent sessions.Cookies allow servers to remember specific informationabout clients.

credentials. Detailed information, acquired duringauthentication, that describes the user, any groupassociations, and other security-related identityattributes. Credentials can be used to perform amultitude of services, such as authorization, auditing,and delegation.

credentials modification service. An authorizationAPI runtime plug-in which can be used to modify anAccess Manager credential. Credentials modificationservices developed externally by customers are limitedto performing operation to add and remove from thecredentials attribute list and only to those attributesthat are considered modifiable.

cross domain authentication service (CDAS). AWebSEAL service that provides a shared librarymechanism that allows you to substitute the defaultWebSEAL authentication mechanisms with a customprocess that returns a Tivoli Access Manager identity toWebSEAL. See also WebSeal.

cross domain mapping framework (CDMF). Aprogramming interface that allows a developer tocustomize the mapping of user identities and the

handling of user attributes when WebSEALe-Community SSO function are used.

Ddaemon. A program that runs unattended to performa standard service. Some daemons are triggeredautomatically to perform their task; others operateperiodically.

directory schema. The valid attribute types and objectclasses that can appear in a directory. The attributetypes and object classes define the syntax of theattribute values, which attributes must be present, andwhich attributes may be present for the directory.

distinguished name (DN). The name that uniquelyidentifies an entry in a directory. A distinguished nameis made up of attribute:value pairs, separated bycommas.

digital signature. In e-commerce, data that isappended to, or is a cryptographic transformation of, adata unit and that enables the recipient of the data unitto verify the source and integrity of the unit and torecognize potential forgery.

DN. See distinguished name.

domain. (1) That part of a computer network in whichthe data processing resources are under commoncontrol. (2) See domain name.

domain name. In the Internet suite of protocols, aname of a host system. A domain name consists of asequence of subnames separated by a delimitercharacter. For example, if the fully qualified domainname of a host system is ralvm7.vnet.ibm.com, each ofthe following is a domain name:

v ralvm7.vnet.ibm.com

v vnet.ibm.com

v ibm.com

EEAS. See External Authorization Service.

encryption. In computer security, the process oftransforming data into an unintelligible form in such away that the original data either cannot be obtained orcan be obtained only by using a decryption process.

entitlement. A data structure that containsexternalized security policy information. Entitlementscontain policy data or capabilities that are formatted ina way that is understandable to a specific application.

entitlements service. An authorization API runtimeplug-in which can be used to return entitlements froman external source for a principal or set of conditions.Entitlements are normally application specific data that


will be consumed by the resource manager applicationin some way or added to the principal’s credentials foruse further on in the authorization process. Customersmay develop these services using the AuthorizationADK.

external authorization service. An authorization APIruntime plug-in that can be used to make applicationor environment specific authorization decisions as partof the Access Manager authorization decision chain.Customers may develop these services using theAuthorization ADK.

Ffile transfer protocol (FTP). In the Internet suite ofprotocols, an application layer protocol that usesTransmission Control Protocol (TCP) and Telnetservices to transfer bulk-data files between machines orhosts.

Gglobal signon (GSO). A flexible single signon solutionthat enables the user to provide alternative user namesand passwords to the back-end Web application server.Global signon grants users access to the computingresources they are authorized to use — through asingle login. Designed for large enterprises consistingof multiple systems and applications withinheterogeneous, distributed computing environments,GSO eliminates the need for users to manage multipleuser names and passwords. See also single signon.

GSO. See global signon.

Hhost. A computer that is connected to a network (suchas the Internet or an SNA network) and provides anaccess point to that network. Also, depending on theenvironment, the host may provide centralized controlof the network. The host can be a client, a server, orboth a client and a server simultaneously.

HTTP. See Hypertext Transfer Protocol.

hypertext transfer protocol (HTTP). In the Internetsuite of protocols, the protocol that is used to transferand display hypertext documents.

IInternet protocol (IP). In the Internet suite ofprotocols, a connectionless protocol that routes datathrough a network or interconnected networks and actsas an intermediary between the higher protocol layersand the physical network.

Internet suite of protocols. A set of protocolsdeveloped for use on the Internet and published asRequests for Comments (RFCs) through the InternetEngineering Task Force (IETF).

interprocess communication (IPC). A method forallowing a program to handle many user requests atthe same time via the creation and management ofindividual program processes running concurrently inan operating system.

IP. See Internet Protocol.

IPC. See Interprocess Communication.

Jjunction. An HTTP or HTTPS connection between afront-end WebSEAL server and a back-end Webapplication server. Junctions logically combine the Webspace of the back-end server with the Web space of theWebSEAL server, resulting in a unified view of theentire Web object space. A junction allows WebSEAL toprovide protective services on behalf of the back-endserver. WebSEAL performs authentication andauthorization checks on all requests for resources beforepassing those requests across a junction to the back-endserver. Junctions also allow a variety of single signonsolutions between a client and the junctioned back-endapplication.

Kkey. In computer security, a sequence of symbols thatis used with a cryptographic algorithm for encryptingor decrypting data. See private key and public key.

key database file. See key ring.

key file. See key ring.

key pair. In computer security, a public key and aprivate key. When the key pair is used for encryption,the sender uses the public key to encrypt the message,and the recipient uses the private key to decrypt themessage. When the key pair is used for signing, thesigner uses the private key to encrypt a representationof the message, and the recipient uses the public key todecrypt the representation of the message for signatureverification.

key ring. In computer security, a file that containspublic keys, private keys, trusted roots, and certificates.

LLDAP. See Lightweight Directory Access Protocol.

lightweight directory access protocol (LDAP). Anopen protocol that (a) uses TCP/IP to provide access todirectories that support an X.500 model and (b) does

Glossary 159

not incur the resource requirements of the morecomplex X.500 Directory Access Protocol (DAP).Applications that use LDAP (known asdirectory-enabled applications) can use the directory asa common data store and for retrieving informationabout people or services, such as e-mail addresses,public keys, or service-specific configurationparameters. LDAP was originally specified in RFC1777. LDAP version 3 is specified in RFC 2251, and theIETF continues work on additional standard functions.Some of the IETF-defined standard schemas for LDAPare found in RFC 2256.

lightweight third party authentication (LTPA). Anauthentication framework that allows single signonacross a set of Web servers that fall within an Internetdomain.

LTPA. See lightweight third party authentication.

Mmanagement server. Obsolete. See policy server.

metadata. Data that describes the characteristics ofstored data.

migration. The installation of a new version or releaseof a program to replace an earlier version or release.

multi-factor authentication. A protected object policy(POP) that forces a user to authenticate using two ormore levels of authentication. For example, the accesscontrol on a protected resource can require that theusers authenticate with both user name/password anduser name/token passcode. See also protected objectpolicy.

multiplexing proxy agent (MPA). A gateway thataccommodates multiple client access. These gatewaysare sometimes known as Wireless Access Protocol(WAP) gateways when clients access a secure domainusing a WAP. Gateways establish a single authenticatedchannel to the origin server and ″tunnel″ all clientrequests and responses through this channel.

Nnetwork-based authentication. A protected objectpolicy (POP) that controls access to objects based on theinternet protocol (IP) address of the user. See alsoprotected object policy.

PPAC. See privilege attribute certificate.

permission. The ability to access a protected objectsuch as a file or directory. The number and meaning ofpermissions for an object are defined by the accesscontrol list.

policy. A set of rules that are applied to managedresources.

policy data. Includes both password strength policydata and login data.

policy server. The Tivoli Access Manager server thatmaintains the location information about other serversin the secure domain.

polling. A channel access method (CAM) protocolwhere a request for data is made. In a master/slavescenario, the master queries each slave device in turnas to whether it has any data to transmit. If the slaveanswers yes then the device is permitted to transmit itsdata. If the slave answers no then the master moves onand polls the next slave device. The process is repeatedcontinuously. For Tivoli Access Manager, the WebSEALserver can be configured to regularly poll the masterauthorization (policy) database for update information.

POP. See protected object policy.

portal. An integrated Web site that dynamicallyproduces a customized list of Web resources, such aslinks, content, or services, available to a specific user,based on the access permissions for the particular user.

privilege attribute certificate. Describes a container ofdata, defined externally to the Tivoli Access Managersecure domain, that contains a principal’sauthentication and authorization attributes as well ascapabilities.

privilege attribute certificate service. (1) In TivoliAccess Manager, the privilege attribute certificateservice is used to encode or decode a Tivoli AccessManager credential to or from a format that istransmissable in a text-only environment. The format isa combination of ASN1 and MIME encoding. Theservice is built-in to the Tivoli Access Managerauthorization API. (2) An authorization API runtimeclient plug-in which translates a PAC of apredetermined format in to an Access Managercredential, and vice-versa. These services could also beused to package or marshall an Access Managercredential for transmission to other members of thesecure domain. Customers may develop these servicesusing the Authorization ADK. (3) See also privilegeattribute certificate. (4) Michelle, this term has twodefinitions, which one do you think should be used?

protected object policy (POP). A type of securitypolicy that dictates additional conditions for accessing aprotected resource after a successful ACL policy check.Examples of POPs include time-of-day access andquality of protection level.

protected object space. The virtual objectrepresentation of actual system resources that is usedfor applying ACLs and POPs and used by theauthorization service.


private key. In computer security, a key that is knownonly to its owner. Contrast with public key.

public key. In computer security, a key that is madeavailable to everyone. Contrast with private key.

Qquality of protection. The level of data security,determined by a combination of authentication,integrity, and privacy conditions.

Rregistry. (1) The datastore that maintains the accountinformation for users and groups that are allowed toparticipate in the secure domain. (2) A database thatcontains system configuration information regardingthe user, the hardware, and the programs andapplications that are installed.

replica. A server that contains a copy of the directoryor directories of another server. Replicas back upservers in order to enhance performance or responsetimes and to ensure data integrity.

resource object. The representation of an actualnetwork resource, such as as a service, file, andprogram.

response file. A file that contains a set of predefinedanswers to questions asked by a program and that isused instead of entering those values one at a time.

role activation. The process of applying the accesspermissions to a role.

role assignment. The process of assigning a role to auser, such that the user has the appropriate accesspermissions for the object defined for that role.

routing file. An ASCII file that contains commandsthat control the configuration of messages.

RSA encryption. A system for public-keycryptography used for encryption and authentication. Itwas invented in 1977 by Ron Rivest, Adi Shamir, andLeonard Adleman. The system’s security depends onthe difficulty of factoring the product of two largeprime numbers.

run time. The time period during which a computerprogram is executing. A runtime environment is anexecution environment.

Sscalability. The ability of a network system to respondto increasing numbers of users who access resources.

schema. The set of statements, expressed in a datadefinition language, that completely describe thestructure of a database.

secure domain. The group of users, systems, andresources that share common services and usuallyfunction with a common purpose.

secure sockets layer (SSL). A security protocol thatprovides communication privacy. SSL enablesclient/server applications to communicate in a way thatis designed to prevent eavesdropping, tampering, andmessage forgery. SSL was developed by NetscapeCommunications Corp. and RSA Data Security, Inc.

security management. The management disciplinethat addresses an organization’s ability to control accessto applications and data that are critical to its success.

self-registration. The process by which a user canenter required data and become a registered TivoliAccess Manager user, without the involvement of anadministrator.

service. Work performed by a server. A service can bea simple request for data to be sent or stored (as withfile servers, HTTP servers, e-mail servers, and fingerservers), or it can be more complex work such as thatof print servers or process servers.

silent installation. An installation that does not sendmessages to the console but instead stores messagesand errors in log files. Also, a silent installation can useresponse files for data input. See also response file.

single signon (SSO). The ability of a user to logononce and access multiple applications without havingto logon to each application separately. See also globalsignon.

SSL. See Secure Sockets Layer.

SSO. See Single Signon.

step-up authentication. A protected object policy(POP) that relies on a preconfigured hierarchy ofauthentication levels and enforces a specific level ofauthentication according to the policy set on a resource.The step-up authentication POP does not force the userto authenticate using multiple levels of authenticationto access any given resource but requires the user toauthenticate at a level at least as high as that requiredby the policy protecting a resource.

suffixes. A distinguished name that identifies the topentry in a locally held directory hierarchy. Because ofthe relative naming scheme used in LightweightDirectory Access Protocol (LDAP), this suffix applies toevery other entry within that directory hierarchy. Adirectory server can have multiple suffixes, eachidentifying a locally held directory hierarchy.

Glossary 161

TTivoli Access Manager for Business Integration. ATivoli Access Manager blade, which providescomprehensive security services for IBM MQSeries. Itextends the MQSeries environment to supportend-to-end security across queues.

Tivoli Access Manager for Operating Systems. ATivoli Access Manager blade, which provides thesecurity engine for the Tivoli Identity Director product.The security engine intercepts operating system callsrequiring authorization checks, such as for file access.

token. (1) In a local area network, the symbol ofauthority passed successively from one data station toanother to indicate the station temporarily in control ofthe transmission medium. Each data station has anopportunity to acquire and use the token to control themedium. A token is a particular message or bit patternthat signifies permission to transmit. (2) In local areanetworks (LANs), a sequence of bits passed from onedevice to another along the transmission medium.When the token has data appended to it, it becomes aframe.

transport selector (TSEL). The Open SystemsInterconnection (OSI), equivalent of port numbers inTCP/IP. Also called a TSEL number.

trusted root. In the Secure Sockets Layer (SSL), thepublic key and associated distinguished name of acertificate authority (CA).

TSEL. See transport selector.

Uuniform resource identifier (URI). The method usedto identify the locations of content on the Internet. TheURL (uniform resource locator) is a particular form of aURI that identifies a Web page address. A URI typicallydescribes (a) the mechanism used to access the resource(for example, HTTP, HTTPS, FTP), (b) the specificcomputer where the resource is stored (for example,www.webserver.org), and the specific name of theresource on the computer (for example/products/images/serv.jpg).

uniform resource locator (URL). A sequence ofcharacters that represent information resources on acomputer or in a network such as the Internet. Thissequence of characters includes (a) the abbreviatedname of the protocol used to access the informationresource and (b) the information used by the protocolto locate the information resource. For example, in thecontext of the Internet, these are abbreviated names ofsome protocols used to access various informationresources: http, ftp, gopher, telnet, and news; and thisis the URL for the IBM home page:http://www.ibm.com.

URI. See uniform resource identifier.

URL. See uniform resource locator.

user. Any person, organization, process, device,program, protocol, or system that uses a serviceprovided by others.

user registry. See registry.

Vvirtual hosting. The capability of a Web server thatallows it to appear as more than one host to theInternet.

WWeb Portal Manager (WPM). A Web-based graphicalapplication used to manage Tivoli Access Manager Baseand WebSEAL security policy in a secure domain. Analternative to the pdadmin command line interface, thisGUI enables remote administrator access and enablesadministrators to create delegated user domains andassign delegate administrators to these domains.

WebSEAL. A Tivoli Access Manager blade. WebSEALis a high performance, multi-threaded Web server thatapplies a security policy to a protected object space.WebSEAL can provide single signon solutions andincorporate back-end Web application server resourcesinto its security policy.

WPM. See Web Portal Manager.


Index

Aaccess control list (ACL) 13accessibility xvaccountability 5ACL 13

apply to new LDAP suffixes 101control permission 53create 38custom permissions 42custom permissions example 42default administration policies 58default root 59entries 37entry syntax 38evaluation 43extended action groups 48extended actions 48ID attribute 40inheritance 44management permissions 52operations on an object 42permissions attribute 40resolving request 46traverse 45, 52type attribute 39

ACL permissions 41ACL policies, defining 12action

enter into ACL entries 50action group, create new 49action, create new 50actions 41activating

roles 74administration

delegate role 73enterprise domain 72multiple domains 72roles 73superdomain 72

administration policies (default) 58administrator

multiple domains 72superdomain 72tasks 74

administratorsadministrator 73domain 72enterprise domain 72Policy Director 72predefined 72sec_master 71senior 73support 73types 72

any-other 39, 43audit event 113audit trail 113audit trail files 111, 113auditcfg 115

auditingoverview 111

auditlog 114authentication 3authorization 3, 5authorization API 16authorization API standard 3authorization database, replicate 94authorization evaluator 8authorization model 5authorization policy database 8authorization process 15authorization server 89authorization service 6, 7, 8

authorization API 9management interface 9

auto-database-update-notify 95

Bbooks

feedback xonline xordering x

boot-start-ivacld 94boot-start-ivmgrd 94

Ccentralized management 5configuration files 90container object 31

management 32user-defined 32WebSEAL 32

control permission 53creating

roles 74Customer Support xv

Ddefault administration policies 58default config ACL 59default GSO ACL 59default management ACL 59default Policy ACL 59default replica ACL 59default root ACL 45, 59delegate administrator, illustrated 72delegate role

administration 73delegated administration

administration users and groups 28, 80group ACL permissions 84group and user management 81group container objects 82managing policy 86object space management 79user ACL permissions 85


domainadministrators 72enterprise 72multiple 72subdomain, described 71superdomain 72

Ee-mail contact xvencryption

supported standards 4enterprise domain 72error.log 112evaluating an ACL 43event field ID codes 119explicit ACL 44explicit ACL policy 13extended action groups 48extended actions 48external authorization service 20

Ffail-over configuration 97fatal.log 112feedback about publications xvfield ID codes 119

Ggroup 38group container objects 82

IIBM Directory 97inheritance 44inherited ACL 44inherited ACL policy 13iPlanet 97iv-admin group 28ivmgrd-servers group 28

LLDAP

fail-over configuration 97suffixes, new 101

LDAP fail-overpreference values 99

ldap.conf 98local cache mode 17, 19logaudit 114logflush 115logging

overview 111logsize 114

Mmanagement objects 12management server 8, 89management/ACL permissions 52

management/Action permissions 53management/Config permissions 55management/Groups permissions 57management/GSO permissions 57management/Policy permissions 55management/POP permissions 54management/Replica permissions 56management/Server permissions 55management/Users permissions 56manuals

feedback xonline xordering x

master authorization policy database 8max-notifier-threads 95, 96messages

error.log 112fatal.log 112notice.log 112warning.log 112

multiple domain 72example 72illustrated 72

Nnotice.log 112notification delay time 96notifier-wait-time 95, 96

Oobject permissions 58object space permissions 58object space, user-defined 33

creating new 34object types 34, 82objects, create and delete 35online publications xivordering publications xiv

Ppassword

troubleshooting 73pdacld 89pdadmin 14pdadmin server replicate 95pdmgrd 8, 89permissions 41

custom 42custom, example 42roles 73

Policy Directoradministrators 72authorization service 7, 8core technologies 3introducing 2securing enterprise networks 1

policy enforcer 6POP 14, 61

apply to objects 63configure attributes 63create 62

POP attributeaudit level 64


POP attribute (continued)time of day 64warning mode 64

POP policies, defining 12preference values (LDAP fail-over) 99prerequisite publications xprotected object 12, 31protected object policies 14protected object policy (POP) 61

apply to objects 63configure attributes 63create 62

protected object space 12, 31guidelines 48management objects 12protected object 12system resource 12user-defined objects 12web objects 12

publicationsfeedback xonline xordering x

Qquality of protection 4

Rrelated publications xiiremote cache mode 17, 18replica 99replicate authorization database 94replication 10resolving ACL request 46resource manager 6resource object 31roles

defined 73delegate 73permissions 73role activation 74role assignment 74

assigning 74role creation 74

rollover threshold 114root ACL (default) 45, 59

Sscalability 4, 10sec_master 71securing enterprise networks 1security

common concerns 2implementing policy 11policy 73

serverautomating startup 94

server replicate 95server status 93serviceability messages

error.log 112fatal.log 112notice.log 112

serviceability messages (continued)warning.log 112

sparse ACL model 44status, server 93subdomain 71superdomain 72system resource 12, 31

Ttasks

role activation 74role administration 74role assignment 74role creation 74roles 73types 74

Tivoli Customer Support xvTivoli Information Center xivtraverse 52traverse permission 45, 52

Uunauthenticated 43update notifier threads 96user 38user registry

differences 149user-defined object space 33

creating new 34user-defined objects 12users

administrator, administrator 73administrator, domain 72administrator, Policy Director 72administrator, sec_master 71administrator, senior 73administrator, support 73delegate 73

Wwarning.log 112web objects 12Web Portal Manager 14

security policy 73

Index 165

��

Printed in U.S.A.

SC32-1132-00

base administrator’s guidepublib.boulder.ibm.com/tividd/td/itamos/sc32-1132...this guide is for...

Documents