IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC32-0844-00/en_US/PDF/a… ·...

IBM Tivoli Access Manager

Base Installation GuideVersion 3.9

GC32-0844-00

IBM Tivoli Access Manager

Base Installation GuideVersion 3.9

GC32-0844-00

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

Second Edition (April 2002)

This edition replaces GC32-0815-00.

© Copyright International Business Machines Corporation 2001, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiRelease information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiBase information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiWebSEAL information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiWeb security information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiDeveloper references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiTechnical supplements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiIBM DB2® Universal Database™ . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiIBM Global Security Toolkit. . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiIBM SecureWay Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . xivIBM WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Accessing publications online . . . . . . . . . . . . . . . . . . . . . . . . . . . . xivOrdering publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvProviding feedback about publications . . . . . . . . . . . . . . . . . . . . . . . . . xv

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

Typeface conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Chapter 1. IBM Tivoli Access Manager Installation overview . . . . . . . . . . . . . 1Planning for deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Secure domain overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Installation components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Access Manager application development kit . . . . . . . . . . . . . . . . . . . . . . . 3Access Manager authorization server . . . . . . . . . . . . . . . . . . . . . . . . . . 3Access Manager Java Runtime Environment . . . . . . . . . . . . . . . . . . . . . . . . 3Access Manager policy server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Access Manager runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Access Manager Web portal manager . . . . . . . . . . . . . . . . . . . . . . . . . . 4IBM Global Security Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4IBM SecureWay Directory client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Disk space and memory requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 5Supported operating systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Supported user registries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

IBM SecureWay Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6iPlanet Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7LiveContent DIRECTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Lotus Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Microsoft Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8OS/390 Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9z/OS Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Access Manager Java Runtime Environment . . . . . . . . . . . . . . . . . . . . . . . . 9Access Manager Web portal manager . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Supported operating systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Supported browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

IBM Global Security Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10IBM SecureWay Directory client . . . . . . . . . . . . . . . . . . . . . . . . . . . 11IBM Tivoli Access Manager compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11

Installation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

© Copyright IBM Corp. 2001, 2002 iii

Installation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Easy installation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Native installation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Internationalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Enabling language support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Installing language support packages . . . . . . . . . . . . . . . . . . . . . . . . . 15Installing language packages for prerequisite software . . . . . . . . . . . . . . . . . . . 17Uninstalling language support packages . . . . . . . . . . . . . . . . . . . . . . . . 19Locale environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Message catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Text encoding (code set) support . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Location of code set files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Code set files provided . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 2. Configuring supported user registries for IBM Tivoli Access Manager. . . . 25Setting up Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Active Directory considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Creating an Active Directory domain . . . . . . . . . . . . . . . . . . . . . . . . . . 26Joining an Active Directory domain . . . . . . . . . . . . . . . . . . . . . . . . . . 26Creating an Active Directory administrative user . . . . . . . . . . . . . . . . . . . . . . 31Active Directory replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Configuring Lotus Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32LDAP server configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Configuring the IBM SecureWay Directory server. . . . . . . . . . . . . . . . . . . . . . . 34Configuring the iPlanet Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . 39Configuring LiveContent DIRECTORY . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Loading the IBM Tivoli Access Manager schema file . . . . . . . . . . . . . . . . . . . . . 44Adding object and attribute type definitions . . . . . . . . . . . . . . . . . . . . . . 44Updating LiveContent DIRECTORY search suffixes . . . . . . . . . . . . . . . . . . . . 46

Configuring the LiveContent DIRECTORY DAP port . . . . . . . . . . . . . . . . . . . . 46Configuring the IBM Tivoli Access Manager host system . . . . . . . . . . . . . . . . . . . 47

Obtaining files from LiveContent DIRECTORY . . . . . . . . . . . . . . . . . . . . . 47Configuring and verifying bindings . . . . . . . . . . . . . . . . . . . . . . . . . 48

Updating LiveContent DIRECTORY DAC schemas . . . . . . . . . . . . . . . . . . . . . 48Configuring z/OS or OS/390 security servers . . . . . . . . . . . . . . . . . . . . . . . . 49

Creating a DB2 database for the TDBM backend . . . . . . . . . . . . . . . . . . . . . . 50Creating an LDAP configuration file for a TDBM backend. . . . . . . . . . . . . . . . . . . 50Starting the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Updating and loading schema files . . . . . . . . . . . . . . . . . . . . . . . . . . 51Enabling LDAP replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Adding a stanza to the replica LDAP server’s configuration file . . . . . . . . . . . . . . . . 52Add an object to the master LDAP server’s backend. . . . . . . . . . . . . . . . . . . . 52

Configuring IBM Tivoli Access Manager for LDAP . . . . . . . . . . . . . . . . . . . . . 53Native authentication user administration . . . . . . . . . . . . . . . . . . . . . . . . 53

Chapter 3. Installing IBM Tivoli Access Manager on AIX . . . . . . . . . . . . . . 55Using easy installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Easy installation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Easy installation scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Easy installation configuration options . . . . . . . . . . . . . . . . . . . . . . . . . 57

IBM SecureWay Directory server . . . . . . . . . . . . . . . . . . . . . . . . . . 57Access Manager runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Policy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Authorization server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Using response files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Creating a response file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Installing components using a response file. . . . . . . . . . . . . . . . . . . . . . . 61Response file example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Response file stanza-keyword options . . . . . . . . . . . . . . . . . . . . . . . . 63

Using native installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

iv IBM Tivoli Access Manager: Base Installation Guide

Native installation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Installing the IBM Global Security Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 65Installing the IBM SecureWay Directory client . . . . . . . . . . . . . . . . . . . . . . . 66Installing and configuring IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . 66Installing and configuring the Access Manager Java Runtime Environment . . . . . . . . . . . . . 67Installing and configuring Web portal manager . . . . . . . . . . . . . . . . . . . . . . 68

Web portal manager installation considerations . . . . . . . . . . . . . . . . . . . . . 68Installing IBM WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . 69Installing IBM WebSphere Application Server FixPack 2 . . . . . . . . . . . . . . . . . . 70

Native installation configuration options. . . . . . . . . . . . . . . . . . . . . . . . . 71Access Manager runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Policy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Authorization server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Default ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Uninstalling IBM Tivoli Access Manager. . . . . . . . . . . . . . . . . . . . . . . . . . 74

Uninstallation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Unconfiguring IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . 74Removing IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . 75

Chapter 4. Installing IBM Tivoli Access Manager on HP-UX . . . . . . . . . . . . . 77Using easy installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77


Access Manager runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Policy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Authorization server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Using response files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Creating a response file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Installing components using a response file. . . . . . . . . . . . . . . . . . . . . . . 82Response file example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Response file stanza-keyword options . . . . . . . . . . . . . . . . . . . . . . . . 83

Using native installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Native installation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Installing the IBM Global Security Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 85Installing the IBM SecureWay Directory client . . . . . . . . . . . . . . . . . . . . . . . 85Installing and configuring IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . 86Installing and the configuring Access Manager Java Runtime Environment . . . . . . . . . . . . . 86Native installation configuration options. . . . . . . . . . . . . . . . . . . . . . . . . 87

Access Manager runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Policy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Authorization server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Default ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Uninstalling IBM Tivoli Access Manager. . . . . . . . . . . . . . . . . . . . . . . . . . 90

Uninstallation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Unconfiguring IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . 90Removing IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . 91

Chapter 5. Installing IBM Tivoli Access Manager on Linux. . . . . . . . . . . . . . 93Using easy installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93


Access Manager runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Using response files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Creating a response file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Installing components using a response file. . . . . . . . . . . . . . . . . . . . . . . 95Response file example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Response file stanza-keyword options . . . . . . . . . . . . . . . . . . . . . . . . 96

Using native installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Contents v

Native installation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Installing the IBM Global Security Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 98Installing the IBM SecureWay Directory client . . . . . . . . . . . . . . . . . . . . . . . 98Installing and configuring IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . 98Access Manager runtime configuration options . . . . . . . . . . . . . . . . . . . . . . 99Installing and the configuring Access Manager Java Runtime Environment . . . . . . . . . . . . . 99

Uninstalling IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . 100Uninstallation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Unconfiguring IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . 101Removing IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . 101

Chapter 6. Installing IBM Tivoli Access Manager on Solaris . . . . . . . . . . . . 103Using easy installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Easy installation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Easy installation scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Easy installation configuration options . . . . . . . . . . . . . . . . . . . . . . . . . 105

IBM SecureWay Directory server . . . . . . . . . . . . . . . . . . . . . . . . . . 105Access Manager runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Policy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Authorization server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Using response files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Creating a response file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Installing components using a response file . . . . . . . . . . . . . . . . . . . . . . 109Response file example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Response file stanza-keyword options . . . . . . . . . . . . . . . . . . . . . . . . 111

Using native installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Native installation considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . 113Installing the IBM Global Security Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 113Installing the IBM SecureWay Directory client . . . . . . . . . . . . . . . . . . . . . . 114Installing and configuring IBM Tivoli Access Manager. . . . . . . . . . . . . . . . . . . . 114Installing and the configuring Access Manager Java Runtime Environment . . . . . . . . . . . . . 115Installing and configuring Web portal manager . . . . . . . . . . . . . . . . . . . . . . 116

Web portal manager installation considerations . . . . . . . . . . . . . . . . . . . . . 116Installing IBM WebSphere Application Server. . . . . . . . . . . . . . . . . . . . . . 118Installing IBM WebSphere Application Server FixPack 2 . . . . . . . . . . . . . . . . . . 118

Native installation configuration options . . . . . . . . . . . . . . . . . . . . . . . . 119Access Manager runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Policy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Authorization server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Default ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Uninstalling IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . 122

Uninstallation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Unconfiguring IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . 122Removing IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . 123

Chapter 7. Installing IBM Tivoli Access Manager on Windows . . . . . . . . . . . 125Using easy installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Easy installation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Easy installation scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Easy installation configuration options . . . . . . . . . . . . . . . . . . . . . . . . . 127

IBM SecureWay Directory server . . . . . . . . . . . . . . . . . . . . . . . . . . 128Access Manager runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Policy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Authorization server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Using response files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Creating a response file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Installing components using a response file . . . . . . . . . . . . . . . . . . . . . . 131Response file example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Response file stanza-keyword options . . . . . . . . . . . . . . . . . . . . . . . . . 133Using native installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

vi IBM Tivoli Access Manager: Base Installation Guide

Native installation considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . 135Installing the IBM Global Security Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 136Installing the IBM SecureWay Directory client . . . . . . . . . . . . . . . . . . . . . . 136Installing and configuring IBM Tivoli Access Manager. . . . . . . . . . . . . . . . . . . . 137Installing and configuring the Access Manager Java Runtime Environment . . . . . . . . . . . . . 138Installing and configuring Web portal manager . . . . . . . . . . . . . . . . . . . . . . 139

Web portal manager installation considerations . . . . . . . . . . . . . . . . . . . . . 140Installing IBM WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . 141Installing IBM WebSphere Application Server FixPack 2 . . . . . . . . . . . . . . . . . . 143

Native installation configuration options . . . . . . . . . . . . . . . . . . . . . . . . 144Access Manager runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Policy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Authorization server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Default ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Uninstalling IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . 148

Uninstallation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Unconfiguring IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . 148Removing IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . 149

Chapter 8. Enabling Secure Sockets Layer for LDAP registries . . . . . . . . . . . 151Configuring the IBM SecureWay Directory server for SSL access . . . . . . . . . . . . . . . . . 151

Creating the key database file and the certificate . . . . . . . . . . . . . . . . . . . . . 152Obtaining a personal certificate from a certificate authority . . . . . . . . . . . . . . . . . . 153Creating and extracting a self-signed certificate . . . . . . . . . . . . . . . . . . . . . . 153Enabling SSL access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Configuring the iPlanet Directory server for SSL access . . . . . . . . . . . . . . . . . . . . 156Obtaining a server certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Installing the server certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Enabling SSL access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Configuring OS/390 and z/OS SecureWay LDAP servers for SSL access. . . . . . . . . . . . . . . 158Create a key database file for the server . . . . . . . . . . . . . . . . . . . . . . . . 159Create a self-signed certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Store the server certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Add a security stanza to the LDAP configuration file . . . . . . . . . . . . . . . . . . . . 160Restart the LDAP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Configuring the IBM SecureWay Directory client for SSL access . . . . . . . . . . . . . . . . . 161Creating a key database file . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Adding a signer certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Testing SSL access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Configuring LDAP server and client authentication. . . . . . . . . . . . . . . . . . . . . . 163Creating a key database file . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Obtaining a personal certificate from a certificate authority . . . . . . . . . . . . . . . . . . 165Creating and extracting a self-signed certificate . . . . . . . . . . . . . . . . . . . . . . 165Adding a signer certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Testing the SSL access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Chapter 9. Enabling Secure Sockets Layer for Lotus Domino. . . . . . . . . . . . 169Creating the SSL key ring file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Enabling SSL access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Creating an IBM Tivoli Access Manager administrative user for Domino . . . . . . . . . . . . . . 170

Appendix A. Upgrading to IBM Tivoli Access Manager. . . . . . . . . . . . . . . 171Upgrade considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Upgrading from Version 3.7.1 with DCE . . . . . . . . . . . . . . . . . . . . . . . . . 173

Upgrading a Version 3.7.1 policy server with DCE . . . . . . . . . . . . . . . . . . . . . 173Upgrading other Version 3.7.1 systems with DCE . . . . . . . . . . . . . . . . . . . . . 176

Upgrading from Version 3.7.1 with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . 178Upgrading a Version 3.7.1 policy server with LDAP . . . . . . . . . . . . . . . . . . . . 178Upgrading a Version 3.7.1 policy server with LDAP using two systems . . . . . . . . . . . . . . 181Upgrading other Version 3.7.1 systems with LDAP . . . . . . . . . . . . . . . . . . . . . 183

Contents vii

Retiring the Tivoli SecureWay Policy Director, Version 3.7.1, policy server . . . . . . . . . . . . . 186Upgrading from Version 3.8 with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . 186

Upgrading a Version 3.8 policy server with LDAP . . . . . . . . . . . . . . . . . . . . . 186Upgrading a Version 3.8 policy server with LDAP using two systems . . . . . . . . . . . . . . 187Upgrading other Version 3.8 systems with LDAP . . . . . . . . . . . . . . . . . . . . . 189Retiring the Tivoli SecureWay Policy Director 3.8 Policy Server . . . . . . . . . . . . . . . . . 190

Editing the migration configuration file. . . . . . . . . . . . . . . . . . . . . . . . . . 190Backing up Access Manager data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Restoring Access Manager data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Restoring a system to Version 3.7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Restoring a system to Version 3.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Appendix B. OS/390 and z/OS LDAP configuration reference . . . . . . . . . . . . 199Sample LDAP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Sample DB2 database and tablespace script for SPUFI . . . . . . . . . . . . . . . . . . . . . 200Sample DB2 index script for SPUFI . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Sample CLI bind batch job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Sample CLI initialization file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Appendix C. Easy installation scenarios . . . . . . . . . . . . . . . . . . . . . 211Creating a secure domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211Installing Web portal manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Appendix D. Installation commands. . . . . . . . . . . . . . . . . . . . . . . 219Command syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219migrate37 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220migrate39 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223pdbackup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226pdjrtecfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230pdupgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Appendix E. Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233XML Parser Toolkit License. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Pluggable Authentication Module License . . . . . . . . . . . . . . . . . . . . . . . . . 235Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

viii IBM Tivoli Access Manager: Base Installation Guide

Preface

IBM® Tivoli® Access Manager (Access Manager) is the base software that isrequired to run applications in the Access Manager product suite. It enables theintegration of Access Manager applications that provide a wide range ofauthorization and management solutions. Sold as an integrated solution, theseproducts provide an access control management solution that centralizes networkand 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, theterm management server is now referred to as policy server.

The IBM Tivoli Access Manager Base Installation Guide explains how to install,configure, and upgrade Access Manager base software, including the Web portalmanager—a Web-based interface that enables you to perform server administrationtasks.

Who should read this bookThis guide is for system administrators responsible for the installation anddeployment of IBM Tivoli Access Manager.

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 A supported user registryv Authentication and authorization

If you are enabling Secure Sockets Layer (SSL) communication, you also should befamiliar with SSL protocol, key exchange (public and private), digital signatures,cryptographic algorithms, and certificate authorities.

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

Describes Access Manager components, explains easy and native installationoptions, and lists the steps that you need to follow to set up an Access Managersecure domain. This chapter also lists system requirements necessary to installand configure IBM Tivoli Access Manager Base software.

v Chapter 2, “Configuring supported user registries for IBM Tivoli AccessManager” on page 25Describes how to set up and configure supported user registries for use withIBM Tivoli Access Manager.

© Copyright IBM Corp. 2001, 2002 ix

v Chapter 3, “Installing IBM Tivoli Access Manager on AIX” on page 55Provides instructions on how to install and configure Access Managercomponents on AIX systems using easy installation scripts or native operatingsystem utilities. Also provides instructions for unconfiguring and removingAccess Manager components.

v Chapter 4, “Installing IBM Tivoli Access Manager on HP-UX” on page 77Provides instructions on how to install and configure Access Managercomponents on HP-UX systems using easy installation scripts or nativeoperating system utilities. Also provides instructions for unconfiguring andremoving Access Manager components.

v Chapter 5, “Installing IBM Tivoli Access Manager on Linux” on page 93Provides instructions on how to install and configure Access Managercomponents on Linux systems using easy installation scripts or native operatingsystem utilities. Also provides instructions for unconfiguring and removingAccess Manager components.

v Chapter 6, “Installing IBM Tivoli Access Manager on Solaris” on page 103Provides instructions on how to install and configure Access Managercomponents on Solaris systems using easy installation scripts or native operatingsystem utilities. Also provides instructions for unconfiguring and removingAccess Manager components.

v Chapter 7, “Installing IBM Tivoli Access Manager on Windows” on page 125Provides instructions on how to install and configure Access Managercomponents on Windows systems using easy installation scripts or nativeoperating system utilities. Also provides instructions for unconfiguring andremoving Access Manager components.

v Chapter 8, “Enabling Secure Sockets Layer for LDAP registries” on page 151Explains how to enable SSL data encryption for secure communications betweenthe LDAP server and IBM SecureWay Directory clients.

v Chapter 9, “Enabling Secure Sockets Layer for Lotus Domino” on page 169Explains how to enable SSL data encryption for Lotus Domino.

v Appendix A, “Upgrading to IBM Tivoli Access Manager” on page 171Explains how to upgrade an existing Tivoli SecureWay Policy Director, Version3.7.1, or Version 3.8 secure domain to IBM Tivoli Access Manager, Version 3.9.

v Appendix B, “OS/390 and z/OS LDAP configuration reference” on page 199Provides reference information when configuring an OS/390 or z/OS SecurityServer for use with IBM Tivoli Access Manager.

v Appendix C, “Easy installation scenarios” on page 211Provides step-by-step examples with illustrations on how to install andconfigure a secure domain using easy installation scripts. Also illustrates how toinstall and configure the Web portal manager interface and prerequisite software.

v Appendix D, “Installation commands” on page 219Provides reference information about commands related to installing,configuring, and upgrading to IBM Tivoli Access Manager.

v Appendix E, “Notices” on page 233v “Glossary” on page 237

x IBM Tivoli Access Manager: Base Installation Guide

PublicationsThis section lists publications in the Access Manager library and any other relateddocuments. It also describes how to access Tivoli publications online, how to orderTivoli publications, and how to make comments on Tivoli publications.

IBM Tivoli Access ManagerThe Access Manager library is organized into the following categories:v Release informationv Base informationv WebSEAL informationv Web security informationv Developer reference informationv Supplemental technical information

Publications in the product library are included in Portable Document Format(PDF) on the product CD. To access these publications using a Web browser, openthe infocenter.html file, which is located in the /doc directory on the product CD.

For additional sources of information about Access Manager and related topics, seethe following Web sites:

http://www.ibm.com/redbooks

https://www.tivoli.com/secure/support/documents/fieldguides

Release informationv IBM Tivoli Access Manager for e-business Read Me First GI11-0918

(am39_readme.pdf)Provides information for installing and getting started using Access Manager.

v IBM Tivoli Access Manager for e-business Release Notes GI11-0919(am39_relnotes.pdf)Provides late-breaking information, such as software limitations, workarounds,and documentation updates.

Base informationv IBM Tivoli Access Manager Base Installation Guide GC32-0844 (am39_install.pdf)

Provides installation, configuration, and upgrade instructions for AccessManager base software, including the Web portal manager interface.

v IBM Tivoli Access Manager Base Administrator’s Guide GC23-4684 (am39_admin.pdf)Describes the concepts and procedures for using Access Manager services.Provides instructions for performing tasks from the Web portal managerinterface and by using the pdadmin command.

v IBM Tivoli Access Manager Base for Linux on zSeries™ Installation Guide GC23-4796(am39_zinstall.pdf)Explains how to install and configure Access Manager Base for Linux on thezSeries platform.

WebSEAL informationv IBM Tivoli Access Manager WebSEAL Installation Guide GC32-0848

(amweb39_install.pdf)

Preface xi

Provides installation, configuration, and upgrade instructions for the WebSEALserver and the WebSEAL application development kit.

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

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

v IBM Tivoli Access Manager WebSEAL for Linux on zSeries Installation GuideGC23-4797 (amweb39_zinstall.pdf)Provides installation, configuration, and removal instructions for WebSEALserver and the WebSEAL application development kit for Linux on the zSeriesplatform.

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

(amwas39_user.pdf)Provides installation, configuration, and administration instructions for AccessManager for IBM WebSphere® Application Server.

v IBM Tivoli Access Manager for WebLogic Server User’s Guide GC32-0851(amwls39_user.pdf)Provides installation, configuration, and administration instructions for AccessManager for BEA WebLogic Server.

v IBM Tivoli Access Manager Plug-in for Edge Server User’s Guide GC23-4685(amedge39_user.pdf) Provides installation, configuration, and administrationinstructions for the plug-in for Edge Server application.

v IBM Tivoli Access Manager Plug-in for Web Servers User’s Guide GC23-4686(amws39_user.pdf)Provides installation, configuration, and administration instructions for securingyour Web domain using the plug-in for Web servers application.

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

(am39_authC_devref.pdf)Provides reference material that describes how to use the Access Managerauthorization C API and the Access Manager service plug-in interface to addAccess Manager security to applications.

v IBM Tivoli Access Manager Authorization Java Classes Developer’s ReferenceGC23-4688 (am39_authJ_devref.pdf)Provides reference information for using the Java™ language implementation ofthe authorization API to enable an application to use Access Manager security.

v IBM Tivoli Access Manager Administration C API Developer’s Reference GC32-0843(am39_adminC_devref.pdf)Provides reference information about using the administration API to enable anapplication to perform Access Manager administration tasks. This documentdescribes the C implementation of the administration API.

xii IBM Tivoli Access Manager: Base Installation Guide

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

v IBM Tivoli Access Manager WebSEAL Developer’s Reference GC23-4683(amweb39_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 Performance Tuning Guide GC43-0846

(am39_perftune.pdf)Provides performance tuning information for an environment consisting ofAccess Manager with IBM SecureWay Directory defined as the user registry.

v IBM Tivoli Access Manager Capacity Planning Guide GC32-0847 (am39_capplan.pdf)Assists planners in determining the number of WebSEAL, LDAP, and backendWeb servers needed to achieve a required workload.

v IBM Tivoli Access Manager Error Message Reference SC32-0845(am39_error_ref.pdf)Provides explanations and recommended actions for the messages produced byAccess Manager.

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

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

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

IBM DB2® Universal Database™

IBM DB2 Universal Database is required when installing IBM SecureWay Directory,z/OS™, and OS/390® SecureWay LDAP servers. DB2 information is available atthe following Web site:

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

IBM Global Security ToolkitAccess Manager provides data encryption through the use of IBM Global SecurityToolkit (GSKit). GSKit is shipped on the IBM Tivoli Access Manager Base CD foryour 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 in the /doc/GSKit directory: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 Access Manager secure domain.

Preface xiii

IBM SecureWay DirectoryIBM SecureWay Directory, Version 3.2.2, is shipped on the IBM Tivoli AccessManager Base CD for your particular platform. If you plan to install the IBMSecureWay Directory server as your user registry, the following documents areavailable in the /doc/Directory path on the IBM Tivoli Access Manager Base CDfor your particular platform:v IBM SecureWay Directory Installation and Configuration Guide (aparent.pdf,

lparent.pdf, sparent.pdf, wparent.pdf)Provides installation, configuration, and migration information for IBMSecureWay Directory components on AIX®, Linux, Solaris, and Microsoft®

Windows® operating systems.v IBM SecureWay Directory Release Notes (relnote.pdf)

Supplements IBM SecureWay Directory, Version 3.2.2, product documentationand describes features and functions made available to you in this release.

v IBM SecureWay Directory Readme Addendum (addendum322.pdf)Provides information about changes and fixes that occurred after the IBMSecureWay Directory documentation had been translated. This file is in Englishonly.

v IBM SecureWay Directory Server Readme (server.pdf)Provides a description of the IBM SecureWay Directory Server, Version 3.2.2.

v IBM SecureWay Directory Client Readme (client.pdf)Provides a description of the IBM SecureWay Directory Client SDK, Version3.2.2. This software development kit (SDK) provides LDAP applicationdevelopment support.

v IBM SecureWay Directory Configuration Schema (scparent.pdf)Describes the directory information tree (DIT) and the attributes that are used toconfigure the slapd32.conf file. In IBM SecureWay Directory Version 3.2, thedirectory settings are stored using the LDAP Directory Interchange Format(LDIF) in the slapd32.conf file.

v IBM SecureWay Directory Tuning Guide (tuning.pdf)Provides performance tuning information for IBM SecureWay Directory. Tuningconsiderations for directory sizes ranging from a few thousand entries tomillions of entries are given where applicable.

For more information about IBM SecureWay Directory, see the following Web site:

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

IBM WebSphere Application ServerIBM WebSphere Application Server, Advanced Single Server Edition 4.0.2, isinstalled with the Web portal manager interface. For information about IBMWebSphere Application Server, see the following Web site:

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

Accessing publications onlinePublications in the product library are included in Portable Document Format(PDF) on the product CD. To access these publications using a Web browser, openthe infocenter.html file, which is located in the /doc directory on the product CD.

When IBM publishes an updated version of one or more online or hardcopypublications, they are posted to the Tivoli Information Center. The Tivoli

xiv IBM Tivoli Access Manager: Base Installation Guide

Information 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 the Tivoli Information Center and other sources of technicalinformation from the following Web site:

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

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 the following Web site:

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

You can also order by telephone by calling one of these numbers:v In the United States: 800-879-2755v In Canada: 800-426-4968v In other countries, for a list of telephone numbers, see the following Web site:

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

Providing feedback about publicationsWe are very interested in hearing about your experience with Tivoli products anddocumentation, and we welcome your suggestions for improvements. If you havecomments or suggestions about our products and documentation, contact us in oneof the following ways:v Send an e-mail to [email protected] Complete our customer feedback survey at the following Web site:

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 can alsouse 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 Tivoli CustomerSupport. See the Tivoli Customer Support Handbook at the following Web site:

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

Preface xv

The handbook provides information about how to contact Tivoli CustomerSupport, depending on the severity of your problem, and the followinginformation: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 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.

xvi IBM Tivoli Access Manager: Base Installation Guide

Chapter 1. IBM Tivoli Access Manager Installation overview

Before you begin installing IBM Tivoli Access Manager (Access Manager), youmust become familiar with its components, installation options, and systemrequirements.

This chapter includes the following sections:v “Planning for deployment”v “Secure domain overview” on page 2v “Installation components” on page 3v “Installation process” on page 11v “Software requirements” on page 5v “IBM Tivoli Access Manager compatibility” on page 11v “Disk space and memory requirements” on page 5v “Internationalization” on page 15

Planning for deploymentBefore you implement a particular Access Manager solution, you must determinethe specific security and management capabilities that are required of yournetwork.

The first step in planning the deployment of an Access Manager securityenvironment is to define the security requirements for your computingenvironment. Defining security requirements means determining the businesspolicies that must apply to users, programs, and data. This includes defining thefollowing:v Objects to be securedv Actions permitted on each objectv Users that are permitted to perform the actions

Enforcing a security policy requires an understanding of the flow of accessrequests through your network topology. This includes identifying proper rolesand locations for firewalls, routers, and subnets. Deploying an Access Managersecurity environment (called a secure domain) also requires identifying the optimalpoints within the network for installing software that evaluates user accessrequests and grants or denies the requested access.

Implementation of a security policy requires understanding the quantity of users,data, and throughput that your network must accommodate. You also mustevaluate performance characteristics, scalability, and the need for failovercapabilities. Integration of legacy software, databases, and applications with AccessManager software must also be considered.

After you have an understanding of the features that you want to deploy, you candecide which Access Manager components and applications can be combined tobest implement your security policy.

© Copyright IBM Corp. 2001, 2002 1

Note: For useful planning documents, see the IBM Tivoli Access Manager CapacityPlanning Guide and applicable field guides located at the following Webaddress for registered users:

https://www.tivoli.com/secure/support/documents/fieldguides

Secure domain overviewThe Access Manager product suite is based on a model that combines a set ofservers and runtime libraries with one or more applications, such as IBM TivoliAccess Manager for Operating Systems. The servers and runtime libraries providea security framework that includes authentication and authorization libraries.

The Access Manager secure domain is a secure computing environment in whichAccess Manager enforces your security policies for authentication, authorization,and access control. Figure 1 represents the systems in a typical secure domain.

For illustration purposes, this graphic depicts a single system for each type ofsetup—policy server, authorization server, and so on. Keep in mind that you canalso install all the software necessary to configure and use a secure domain on onestandalone system. This is useful when prototyping a deployment or developingand testing an application. You might also want to add systems to an existingsecure domain, such as a runtime system or an application development system.

Table 1 on page 3 lists required and optional components for the Access Managersystems illustrated in Figure 1. For descriptions of these components, see“Installation components” on page 3.

Figure 1. Example of systems in a secure domain

2 IBM Tivoli Access Manager: Base Installation Guide

Table 1. Types of Access Manager systems

Type of Access Managersystem

Required Components Optional Components

Policy server IBM Global Security ToolkitAccess Manager runtimeIBM SecureWay Directory client*Policy server

Web portal managerAccess Manager JRE

Runtime system IBM Global Security ToolkitAccess Manager runtimeIBM SecureWay Directory client*


Development system IBM Global Security ToolkitAccess Manager runtimeIBM SecureWay Directory client *Access Manager JRE (required for JavaDoc andexamples only)

Web portal manager

Authorization server IBM Global Security ToolkitAccess Manager runtimeIBM SecureWay Directory client*Authorization server


Note: * — If you plan to install Active Directory as your user registry, the IBMSecureWay Directory client is not required on Access Manager systems inyour secure domain.

Installation componentsThis section provides an overview of the installation components that constitute asecure domain.

Access Manager application development kitThe ADK provides a development environment that enables you to codethird-party applications to query the authorization server for authorizationdecisions. The ADK contains support for using both C APIs and Java classes forauthorization and administration functions. This component is optional.

Access Manager authorization serverThe authorization server offloads access control and authorization decisions fromthe policy server. It maintains a replica of the authorization policy database andfunctions as the authorization decision-making evaluator. A separate authorizationserver also provides access to the authorization service for third-party applicationsthat use the Access Manager authorization API in remote cache mode. Thiscomponent is optional.

Access Manager Java Runtime EnvironmentThe Access Manager Java Runtime Environment offers a reliable environment fordeveloping and deploying Java applications in an Access Manager secure domain.Use it to add Access Manager authorization and security services to new orexisting Java applications.

This component is optional. However, if you are a developer using AccessManager Java Runtime Environment classes, this component and the ADK are

Chapter 1. IBM Tivoli Access Manager Installation overview 3

required. For more information, see IBM Tivoli Access Manager Administration JavaClasses Developer’s Reference and the IBM Tivoli Access Manager Authorization JavaClasses Developer’s Reference.

Access Manager policy serverThe policy server, referred to in previous versions as the management server,maintains the master authorization policy database for the secure domain. Thisserver is key to the processing of access control, authentication, and authorizationrequests. It also updates authorization database replicas and maintains locationinformation about other Access Manager servers in the secure domain.

There can be only one instance of the policy server and its master authorizationdatabase in any secure domain at one time. However, you can have a secondserver in standby mode to provide cold failover capabilities. The policy serverreplicates its access control list (ACL) database to all other Access Manager serversin the secure domain.

Access Manager runtimeThe Access Manager runtime contains runtime libraries and supporting files thatapplications can use to access Access Manager servers. You must install the AccessManager runtime or Java Runtime Environment on every system that is part ofyour secure domain.

Access Manager Web portal managerThe Web portal manager is a Web-based graphical application used to managesecurity policy for the secure domain. The Web portal manager providesmanagement and administration of users, groups, roles, permissions, policies, andapplication access provisioning.

The Web portal manager also includes a rich set of delegated management servicesthat enables a business to delegate user administration, group and roleadministration, security administration, and application access provisioning toparticipants (sub-domains) in the business system. These sub-domains can furtherdelegate management and administration to trusted sub-domains under theircontrol, thereby supporting multi-level delegation and management hierarchybased on roles.

This product is shipped separately on the IBM Tivoli Access Manager Web PortalManager CD and is available on AIX, Solaris, and Windows platforms. Thiscomponent is optional.

Note: For information about using the Web portal manager interface, see the IBMTivoli Access Manager Base Administrator’s Guide.

IBM Global Security ToolkitAccess Manager provides data encryption through the use of IBM Global SecurityToolkit (GSKit). The GSKit package installs the iKeyman key management utility(gsk5ikm), which enables you to create key databases, public-private key pairs,and certificate requests. For information about using this utility to enable SSL, seethe Secure Sockets Layer Introduction and iKeyman User’s Guide and Chapter 8,“Enabling Secure Sockets Layer for LDAP registries” on page 151.


IBM SecureWay Directory clientThe IBM SecureWay Directory client supports all supported user registries exceptActive Directory. This client is shipped with IBM SecureWay Directory on the IBMTivoli Access Manager Base CD for your particular platform. You must install andconfigure this client on each system that runs Access Manager.

The IBM SecureWay Directory client installation package includes two graphicaluser interfaces (GUIs). The Web-based Server Administration interface enables youto perform server and database tasks for the IBM SecureWay Directory server. TheDirectory Management Tool (DMT) enables you to browse and edit information inyour directory, such as schema definitions, the directory tree, and data entries.Indepth documentation for each interface is available through the online helpsystems.

Software requirementsAccess Manager, Version 3.9, has specific requirements that must be met before itcan be installed. These include supported operating systems, softwareprerequisites, and necessary patches.

The requirements listed in the following sections constitute the recommendedenvironment for Access Manager components at the time of publication. For themost current information, see the IBM Tivoli Access Manager for e-business ReleaseNotes on the Tivoli Customer Support Web site.

Disk space and memory requirementsFor disk space and memory requirements, see the IBM Tivoli Access Manager fore-business Release Notes available in the Tivoli Information Center on the followingWeb site:

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

Supported operating systemsAccess Manager, Version 3.9, components are supported on the following operatingsystems, except Red Hat Linux, which only supports the Access Manager runtimeenvironment, the Java Runtime Environment, and the ADK:v AIX 4.3.3 and 5.1.0 with the latest patches, including the bos.rte.libpthreads

patch at level 4.3.3.51 or 5.1.0.10 respectivelyYou can download AIX patches from the following Web address:http://www.ibm.com/partnerworld/pwhome.nsf/weblook/home.html

v HP-UX 11.0v Red Hat Linux 7.1 with the following:

– rpm-3.0.5-27mdk.i586.rpm or greater than 3.0.5-27You can download this patch from the following Web address:http://www.redhat.com

v Solaris 2.7 with the following:– For 32-bit Solaris 2.7 systems, the following patches are required:

- 106950-18- 106327-13

– For 64-bit Solaris 2.7 systems, the following patches are required:- 106950-18


- 106327-13- 106300-14

v Solaris 2.8 with the following:– For 32-bit Solaris 2.8 systems, the following patches are required:

- 109147-15- 108434-05

– For 64-bit Solaris 2.8 systems, the following patches are required:- 109147-15- 108434-05- 108435-06

v Windows NT® 4.0 with Service Pack 6av Windows 2000 Advanced Server with Service Pack 2

Supported user registriesAccess Manager supports the following user registries, their supported operatingsystems, and any necessary prerequisite software.

IBM SecureWay DirectoryAccess Manager supports the use of IBM SecureWay Directory, Version 3.2.1, andVersion 3.2.2, as a user registry.

IBM SecureWay Directory, Version 3.2.1, server: This LDAP server is supportedon the following operating systems:v AIX 4.3.3 and 5.1.0 with the latest patches, including the bos.rte.libpthreads

patch at level 4.3.3.51 or 5.1.0.10You can download AIX patches from the following Web address:http://www.ibm.com/partnerworld/pwhome.nsf/weblook/home.html

v Windows NT 4.0 with Service Pack 6av Windows 2000 Advanced Server with Service Pack 2v Solaris 2.7 and 2.8

Note: Because Access Manager uses a Version 3.2.2 client only, IBM SecureWayDirectory, Version 3.2.1, server support depends on the interoperabilitybetween a Version 3.2.2 client and a Version 3.2.1 server.

IBM SecureWay Directory, Version 3.2.2, server: This LDAP server is supportedon the following operating systems:v AIX 4.3.3 and 5.1.0 with the latest patches, including the bos.rte.libpthreads


v Solaris 2.7 and 2.8v Windows NT 4.0 with Service Pack 6av Windows 2000 Advanced Server with Service Pack 2

Prerequisite software for the IBM SecureWay Directory server is as follows.

Note: For IBM SecureWay Directory, the products with an asterisk (*) are shippedon the IBM Tivoli Access Manager Base CD for AIX, Solaris, and Windowssystems.


v IBM DB2 Universal Database Edition, Version 7.2, with FixPack 5*

Note: If using easy installation to install the IBM SecureWay Directory server,FixPack 5 is installed automatically.

v One of the following supported Web servers:– Apache Server 1.3.12– IBM HTTP Server, Version 1.3.12.0*– Lotus Domino Enterprise 5.0.2b Web server– Microsoft Internet Information Server (IIS) 4.0– Netscape Enterprise Server 3.6.3, 4.0– Netscape FastTrack Server 3.01

Attention:

v If you have an existing IBM SecureWay Directory server that you want to usefor Access Manager, ensure that you upgrade the server to the IBM SecureWayDirectory, Version 3.2.2, level. For migration instructions, see the IBM SecureWayDirectory Installation and Configuration Guide in /doc/Directory on the IBM TivoliAccess Manager Base CD for your particular platform.

v If you have a preexisting version of Lightweight Directory Access Protocol(LDAP) from a vendor other than IBM, you must remove it before installing IBMSecureWay Directory.

v To avoid performance impacts, do not enable the Change Log function. TheChange Log function is disabled by default.

iPlanet DirectoryAccess Manager supports the use of Netscape iPlanet Directory, Version 5.0, as auser registry. This LDAP server is supported on Access Manager platforms listed in“Supported operating systems” on page 5.

For installation information, consult the product documentation that came withyour iPlanet Directory server.

Attention:

v If you have an existing Netscape or iPlanet Directory Server that you want touse for Access Manager, ensure that you upgrade the server to the iPlanetDirectory Server, Version 5.0, level. For migration instructions, see the iPlanetDirectory Server, Version 5.0, Installation Guide at the following Web address:http://docs.iplanet.com/docs/manuals/directory.html#dirserver50

v The iPlanet Directory server requires GSKit to be installed only if you install theAccess Manager runtime on the same system. GSKit is not required for SSLbecause the iPlanet Directory Server has built-in SSL capability.

LiveContent DIRECTORYAccess Manager, Version 3.9, supports the use of Critical Path LiveContentDIRECTORY, Release 8A.3, as a user registry. This LDAP server is supported onthe following operating systems:v Solaris 2.7v Windows NT 4.0 with Service Pack 6a

Required patches are as follows:v DSA 8.3.1.3.12v LDAP 8.2.4.8


For installation information, consult the product documentation that came withyour LiveContent DIRECTORY server.

Attention:

v LiveContent DIRECTORY does not support SSL.v If you install LiveContent DIRECTORY and the IBM SecureWay Directory client

on the same system, two copies of LDAP utilities are installed on the system.Ensure that Access Manager uses the utilities provided by the IBM SecureWayDirectory client. The utilities provided with LiveContent DIRECTORY areincompatible with Access Manager.In addition, if you are using Access Manager on a Windows NT system andhave installed LiveContent DIRECTORY to obtain the necessary binaries formanipulating schema, you must ensure that the correct LDAP utilities are calledon the Windows system. Use the following command to verify which vendor’sproduct is being used:ldapsearch -X

If LiveContent DIRECTORY is on the default path, this command displays thevendor’s name and version.

Lotus DominoAccess Manager supports the use of Lotus Domino, Version 5.0.4, as a user registry.This server is supported on the following operating systems:v AIX 4.3.3 and 5.1.0 with the latest patches, including the bos.rte.libpthreads


v HP-UX 11.0v Red Hat Linux 7.1 with the following:

– rpm-3.0.5-27mdk.i586.rpm or greater than 3.0.5-27

Note: You can download this package from the following Web address:http://www.redhat.com

– Linux Mandrake 7.2 Powerpack libstdc++-2.95.2-12mdk.i586.rpm

v Solaris 2.7 and 2.8v Windows NT 4.0 with Service Pack 6av Windows 2000 Advanced Server with Service Pack 2

Attention: When Lotus Domino is used as the registry:v The IBM SecureWay Directory, Version 3.2.2, client is supported on Windows NT

and Windows 2000 platforms only.v GSKit, Version 5.0.4.67, is required if you plan to enable SSL communication

between the IBM SecureWay Directory, Version 3.2.2, client and the LotusDomino server.

Microsoft Active DirectoryAccess Manager supports the use of Microsoft Active Directory as a user registry.This server is supported on Microsoft Windows 2000 Advanced Server with ServicePack 2. Note that the IBM SecureWay Directory client is not required on AccessManager systems in a secure domain using Active Directory.


OS/390 Security ServerAccess Manager supports the use of IBM OS/390 Server, Version 2, Release 10, as auser registry with the following PTFs applied:v APAR OW46344, which provides the configuration files and libraries to support

the Access Manager schemav APAR OW53402, which provides support for empty attribute replace operations

z/OS Security ServerAccess Manager supports the use of IBM z/OS, Version 1, Release 2 and higher, asa user registry with the following PTFs applied:v APAR OW46344, which provides the configuration files and libraries to support

the Access Manager schemav APAR OW53402, which provides support for empty attribute replace operations

Access Manager Java Runtime EnvironmentBefore you install and configure the Access Manager Java Runtime Environment,you must install the following prerequisite JRE for your particular platform. Thefollowing supported JRE versions are available on the IBM Tivoli Access ManagerBase CD for your particular platform.

Note: Use the pdjrtecfg command to configure the Access Manager Java RuntimeEnvironment to use the proper JRE on your system. You can also configurethe Access Manager Java Runtime Environment to several different JREs onthe same system, if so desired.

v On AIX 4.3.3 and 5.1 systems, the following JRE is supported:– Java™ 2 Runtime Environment, Standard Edition (build 1.3.1)– Classic VM (build 1.3.1, J2RE 1.3.1 IBM AIX build ca1311-20011123a (JIT

enabled: jitc))– X11.adt.lib 4.3.3.10

v On Red Hat Linux 7.1 systems, the following JRE is supported:– Java 2 Runtime Environment, Standard Edition (build 1.3.0)– Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010925 (JIT enabled:

jitc))v On Windows 2000 and NT systems, the following JRE is supported:

– Java 2 Runtime Environment, Standard Edition (build 1.3.0)– Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cn130-20010925 (JIT enabled:

jitc))v On Solaris 2.7 and 2.8 systems, the following JRE is supported:

– Java 2 Runtime Environment, Standard Edition (build 1.3.1_01)– Java HotSpot™ Client VM (build 1.3.1_01, mixed mode)

v On HP-UX 11 systems, install Java Hotspot™ Server VM (build 1.3.11.3.1.01-release-010816-13:34-PA_RISC2.0 PA2.0, mixed mode).

Access Manager Web portal managerWhen you install Web portal manager, you must install the following prerequisitesoftware, located on the IBM Tivoli Access Manager Web Portal Manager CDs forAIX, Solaris, and Windows:v IBM Global Security Toolkit, Version 5.0.4.67v IBM SecureWay Directory, Version 3.2.2, clientv Access Manager runtime


v IBM WebSphere Application Server, Advanced Single Server Edition 4.0 withFixPack 2

Note: For systems running in Simplified Chinese, German, and Italian, you mustinstall FixPack 3 instead of FixPack 2. To download FixPack 3 forWebSphere Application Server, Advanced Single Server Edition, Version4.0, see the Support downloads link at the following Web site:

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

For installation instructions, see the Web portal manager installation process in theAccess Manager installation chapter for AIX, Solaris, and Windows platforms.

Supported operating systemsWeb portal manager is supported on AIX, Solaris, and Windows operating systemsas specified in “Supported operating systems” on page 5. In addition to supportedoperating systems listed, software prerequisite products for Web portal managerrequire the following patches:v AIX 4.3.3 with the latest patches, including the following:

– Maintenance level 9 + PTF U478491– bos.adt.prof (4.3.3.53)– bos.rte.libc (4.3.3.55)

v Solaris 2.7 with the following patches:– 107226 - Revision 14 or greater– October 2001 recommended patches

v Solaris 2.8 with the following patches (applied in this order):1. 108652 - Revision 27 or greater2. 148940 - Revision 14 or greater3. 108921 - Revision 11 or greater4. February 2002 recommended patches

Supported browsersWeb portal manager supports the following Web browsers:v Netscape Navigator 4.78 and 6.2v Internet Explorer 5.5 and 6.0

IBM Global Security ToolkitAccess Manager supports IBM Global Security Toolkit (GSKit), Version 5.0.4.67.This product is shipped on the IBM Tivoli Access Manager Base CD for yourparticular platform.

It is recommended that you install an Access Manager patch (containing GSKitupdates), which will be available at the following Web site in the near future:https://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

GSKit, Version 5, is not compatible with GSKit, Version 4.x,; however, theseversions can coexist on the same system.


IBM SecureWay Directory clientAccess Manager supports IBM SecureWay Directory, Version 3.2.2 with e-fix 1. Thisproduct is shipped on the IBM Tivoli Access Manager Base CD for your particularplatform.

It is recommended that you also install the newly-released e-fix 2 patch available atthe following Web site:http://www.ibm.com/software/network/directory/downloads/

The IBM SecureWay Directory client supports user registries specified in“Supported user registries” on page 6 with the exception of Active Directory. Inaddition, this LDAP client is supported on all platforms listed in “Supportedoperating systems” on page 5.

Attention:

v If Lotus Domino is the user registry, the IBM SecureWay Directory client issupported on Windows NT and Windows 2000 platforms only.

v When installing the IBM SecureWay Directory client on a system with a LotusNotes client installed, ensure that the IBM SecureWay Directory client is first inthe PATH environmental variable.

IBM Tivoli Access Manager compatibilityTable 2 lists versions of Access Manager components that can communicate withthe Access Manager, Version 3.9, policy server:

Note: When using Active Directory or Lotus Domino as the user registry, allAccess Manager components must be at the Version 3.9 level.

Table 2. Access Manager compatibility

Policy Server, Version 3.9

WebSEALServer

Web PortalManager

Authorization Server Access ManagerRuntime

Access Manager JavaRuntime Environment

V3.8 V3.9 V3.8 V3.9 V3.8 V3.9 V3.7.1 V3.8 V3.9 V3.9

The binary backward compatibility supported by Access Manager, Version 3.9, forTivoli SecureWay Policy Director, Version 3.7.1, Version 3.8, and Version 3.9,applications is as follows:v Access Manager, Version 3.9, runtime supports applications compiled against the

Tivoli SecureWay Policy Director, Version 3.7.1 SSL-based 3.8 and 3.9 ADKs forall platforms except Solaris (due to compiler issues).

v The Access Manager, Version 3.9, runtime for Solaris supports applicationscompiled against Access Manager, Version 3.9, ADKs.

Installation processTo install IBM Tivoli Access Manager Base and create a secure domain, followthese basic steps:1. Plan your Access Manager deployment. Ensure that you understand the

business security requirements for which Access Manager is being deployed.For information, see “Planning for deployment” on page 1.

2. Decide which combination of Access Manager systems that you want to installand ensure that you meet all software requirements listed on page 5.


3. Choose an installation option to install Access Manager, Version 3.9. Forinformation and instructions, see “Installation options”.

Installation optionsTable 3 lists Access Manager installation options.

Table 3. Installation options

Option Purpose Instructions

Easy installation Use to expedite the installation andconfiguration of a secure domain using anLDAP user registry. Easy installation isalso useful if you want to add an AccessManager component or set up a system inan existing domain.Note: If you plan to configure ActiveDirectory or Domino as your user registry,you cannot use easy installation.

If you want to script the configurationchoices you made during easy installation,you can also use a response file to performa silent, unattended installation of AccessManager components.

See “Easy installationprocess”.

Native installation Use to step through the installation andconfiguration of Access Managercomponents using native operating systemutilities.

See “Native installationprocess” on page 13.

Upgrade Use to upgrade from Tivoli SecureWayPolicy Director, Version 3.7.1 or Version 3.8.

If you are upgrading from a version earlierthan 3.7.1, you must first upgrade to TivoliSecureWay Policy Director, Version 3.7.1.Consult the Version 3.7.1 productdocumentation for installation instructions.

See Appendix A,“Upgrading to IBMTivoli Access Manager”on page 171.

Easy installation processTo install and configure a new Access Manager secure domain using easyinstallation, follow these basic steps.

Note: If you plan to configure Active Directory or Lotus Domino as your userregistry, you cannot use easy installation. See “Native installation process”on page 13.

1. Review easy installation considerations in the Access Manager installationchapter for your particular platform.

2. Install a supported LDAP server and perform basic configuration by doing oneof the following:v Run the ezinstall_ldap_server script to step you through the process of

installing and configuring IBM SecureWay Directory server and itsprerequisites while, at the same time, enabling SSL. For more informationabout this easy installation script, see the Access Manager installation chapterfor your particular platform.

Note: You cannot use the ezinstall_ldap_server script if an existing versionof IBM SecureWay Directory server is installed.


v Install and configure the iPlanet Directory Server, LiveContent DIRECTORY,OS/390, or z/OS SecureWay LDAP servers by consulting your productdocumentation.

v If you have an existing user registry that you want to use for AccessManager, see “Supported user registries” on page 6 for additionalinformation.

3. After installing a supported LDAP server, run the ezinstall_pdmgr script to setup a policy server system. For easy installation considerations and informationabout this easy installation script, see the Access Manager installation chapterfor your particular platform.

Note: The ezinstall_pdmgr script is supported on AIX, Solaris, and Windowssystems only. You cannot use the ezinstall_pdmgr script if an existingversion of IBM SecureWay Directory server is installed.

4. After configuring the policy server, you can set up additional systems in thesecure domain. For example, you can do the following:v Run the ezinstall_pdrte script to install one or more runtime client systems

(without the policy server).v Run the ezinstall_pdauthADK script to install a development system with the

application development kit (ADK).v Run the ezinstall_pdacld script to set up an authorization server system.

5. Optional: If you are developing and deploying Java applications in an AccessManager secure domain, you can install the Access Manager Java RuntimeEnvironment. Because this component is not available using easy installation,follow native installation instructions in the Access Manager installation chapterfor your particular platform.

6. Optional: If you did not install the IBM SecureWay Directory server using theezinstall_ldap_server script, it is recommended that you manually enable SSLbetween your LDAP server and IBM SecureWay Directory clients. Forinstructions, see Chapter 8, “Enabling Secure Sockets Layer for LDAPregistries” on page 151.

Note: The LiveContent DIRECTORY server does not support SSL.

Native installation processThe following procedure shows you how to install all Access Manager componentsin the appropriate order. Depending on your system’s requirements, select only thecomponents that you need to install. For a list of required and optionalcomponents for a specific Access Manager system, see Table 1 on page 3.

To install and configure Access Manager components using native installation,follow these basic steps:1. Review native installation considerations in the Access Manager installation

chapter for your particular platform.2. Install a supported user registry and perform basic configuration. If you have

an existing user registry that you want to use for Access Manager, see“Supported user registries” on page 6 for additional information.For installation instructions, do one of the following:v To install and configure the IBM SecureWay Directory server, see the IBM

SecureWay Installation and Configuration Guide, located in /doc/Directory onthe IBM Tivoli Access Manager Base CD for AIX, Solaris, and Windowsplatforms.


Notes:– IBM DB2 UDB FixPack 5 is required. For AIX and Windows systems, this

patch is installed with IBM DB2. On Solaris systems, you must manuallyinstall FixPack 5. To do so, use the install script in the patches directoryon the IBM Tivoli Access Manager Base for Solaris, Version 3.9 CD.

– On Windows systems, you must install the IBM SecureWay Directoryserver and client at the same time.

v To install and configure Active Directory, Lotus Domino, iPlanet DirectoryServer, LiveContent DIRECTORY, OS/390 or z/OS security servers, consultyour product documentation.

3. On the system where you installed your user registry, do the following:a. Install IBM Global Security Toolkit (GSKit), Version 5.0.4.67. For GSKit

installation instructions, see the Access Manager installation chapter foryour particular platform.Attention: For IBM SecureWay Directory server, a downlevel version ofGSKit is installed when you install this LDAP server. Ensure that youupgrade to GSKit, Version 5.0.4.67 as instructed.

b. Install the IBM SecureWay Directory client. For IBM SecureWay Directoryclient installation instructions, see the Access Manager installation chapterfor your particular platform.

Note: If you installed Active Directory as your user registry, thiscomponents is not required.

4. Optional: If you are using Domino as your user registry, it is recommended thatyou enable SSL communication between your Domino server and IBMSecureWay Directory clients at this time. For instructions, see Chapter 9,“Enabling Secure Sockets Layer for Lotus Domino” on page 169.

5. Configure your user registry for use with Access Manager. For instructions, seeChapter 2, “Configuring supported user registries for IBM Tivoli AccessManager” on page 25.

6. Set up Access Manager systems in your secure domain. Depending on thesystem that you are setting up, install and configure one or more of thefollowing components in this order.

Note: For a list of required and optional components for a specific type ofsystem setup, see Table 1 on page 3Types of Access Manager systems.

v IBM Global Security Toolkit (GSKit) — You must install GSKit beforeinstalling any other Access Manager component. GSKit is a prerequisite tothe Access Manager runtime environment, which is required on all systemsin the secure domain.

v IBM SecureWay Directory client — This client is required on each system thatruns Access Manager except Active Directory.

v Access Manager runtimev Access Manager policy serverv Access Manager authorization serverv Access Manager ADKv Access Manager JREv Access Manager Web portal manager“Access Manager application

development kit” on page 3


For instructions about installing these components, see the Access Managerinstallation chapter for your particular platform.

7. If you are using an LDAP server as your user registry, you can enable SSLcommunication between your LDAP server and IBM SecureWay Directoryclients. For instructions, see Chapter 8, “Enabling Secure Sockets Layer forLDAP registries” on page 151.Notes:v LiveContent DIRECTORY does not support SSL.v Active Directory for Access Manager uses Kerberos for encryption, not SSL.

InternationalizationThis chapter describes the internationalization features for an Access Managersecure domain and how to use them. This section contains the following topics:v Enabling language supportv Text encoding or code set support

Enabling language supportAccess Manager software is translated into the following languages:v Brazilian Portuguesev Czechv Chinese (Simplified)v Chinese (Traditional)v Frenchv Germanv Hungarianv Italianv Japanesev Koreanv Polishv Spanishv Russian

The translations for these languages are provided as language packages on the IBMTivoli Access Manager Language Support CD for each product. To obtain languagesupport for Access Manager, you must install the language support package forthat product. If you do not install the language support package, the associatedproduct displays all text in English. Note that each language is a separatelyinstallable product installation image.

If language support for a product is installed and you upgrade the product, youmust also install the corresponding language support product, if one exists. Referto the upgrade documentation for the specific product to determine if languagesupport is required. If you do not install the language support after upgrading, theassociated product might display some fields and messages in English.

Installing language support packagesTo install language support packages, do the following:1. Install the JRE for your particular platform. To install the JRE, do one of the

following:


v On AIX systems, follow these steps:a. Log on the system as root.b. Insert the IBM Tivoli Access Manager Language Support, Version 3.9 CD.c. At the command prompt, enter the following command:

installp -c -a -g -X -d /dev/cd0 Java131.rte

v On HP-UX systems, follow these steps:a. Log on the system as root.b. Insert the IBM Tivoli Access Manager Language Support, Version 3.9 CD.c. Start pfs_mountd and then pfsd in the background, if these services are

not running, and then mount the CD with the pfs_mount command.d. Enter the following command:

swinstall -s /cd-rom/hp rte_13101os11.depot B9789AA

where /cd-rom/hp is the directory.v On Linux systems, follow these steps:

a. Log on the system as root.b. Insert the IBM Tivoli Access Manager Language Support, Version 3.9 CD.c. Change to the directory /mnt/cdrom/linux where /mnt/cdrom is the mount

point for your CD.d. Enter the following command:

rpm -i IBMJava2-JRE-1.3-10.0.i386.rpm

v On Solaris systems, follow these steps:a. Log on the system as root.b. Insert the IBM Tivoli Access Manager Language Support, Version 3.9 CD.c. Enter the following command:

cp -r /cdrom/cdrom0/solaris/j2re1_3_1_01 install_dir

where /cdrom/cdrom0/solaris is the directory where the JRE package islocated and install_dir is the installation path.

v On Window systems, follow these steps:a. Log in to the Windows domain as a user with Windows administrator

privileges.b. Insert the IBM Tivoli Access Manager Language Support, Version 3.9 CD.c. Enter the following command:

cdrom_drive\windows\JRE\install

where cdrom_drive\windows\JRE is the directory where the JRE package islocated.

d. During installation, you are prompted to install the JRE as the systemJava Virtual Machine. Select yes.

2. Depending on the Access Manager product that you want to install, run one ormore of the following setup scripts. Scripts are used for UNIX systems; batchfiles (.bat extension) are used for Windows systems.

Notes:

a. Depending on your particular platform, ensure that the CD is mounted.After the CD is mounted, change to the root directory on the CD to issueone of the following scripts.


b. If you issue a script without specifying the jre_path, you must ensure thatthe Java executable is part of the PATH statement. Otherwise, issue thescript specifying the jre_path as follows:product_setup jre_path

For example, to install language packages for Access Manager Base, enterthe following:pdlp_setup /usr/bin

where /usr/bin is the path to the Java Runtime Environment.

Scripts are as follows:

pdlp_setup Specifies to install language packages for AccessManager Base.

jrtlp_setup Specifies to install language packages for AccessManager Java Runtime Environment.

wsllp_setup Specifies to install language packages for AccessManager Plug-in for Edge Server.

wpilp_setup Specifies to install language packages for AccessManager Plug-in for Web Servers.

wpmlp_setup Specifies to install language packages for AccessManager Web portal manager.

weblp_setup Specifies to install language packages for AccessManager WebSEAL.

waslp_setup Specifies to install language packages for AccessManager WebSphere Application Server.

3. Click Next to begin installation. The Software License Agreement dialog isdisplayed.

4. To accept the license agreement, select I accept the terms in the licenseagreement and then click Next. A dialog showing a list of language packages isdisplayed.

5. Select the language packages that you want to install and click Next. A dialogshowing the location and features of the language packages you selected isdisplayed.

6. To accept the language packages you selected, click Next. The languagepackages you selected are installed.

7. After the InstallWizard for Access Manager Language Pack has completedsuccessfully, click Finish to close the wizard and restart your system.

Installing language packages for prerequisite softwareIn addition to installing language packages for Access Manager software, you mustinstall language packages for IBM HTTP Server and IBM SecureWay Directoryproducts. These language packages, provided on the IBM Tivoli Access ManagerLanguage Support, Version 3.9 CD, are required on AIX and Solaris systems only.1. To install the prerequisite language packages, do one of the following:

v For AIX systems, enter the following command:installp -c -a -g -X -d /dev/cd0 package

where package, located in the usr/sys/inst.images directory, is one or moreof the following:


http-server.html.lang Specifies IBM HTTP Server documentation.

http-server.msg.lang.admin Specifies IBM HTTP Server messages.

http-server.msg.lang.ssl.core Specifies IBM HTTP Server SSL messages.

ldap.html.lang Specifies IBM SecureWay Directorydocumentation.

ldap.msg.lang Specifies IBM SecureWay Directory messages.

db2_07_01.msg.lang Specifies DB2 product messages.

where lang is the language file abbreviation.

For example, to install the HTTP Server documentation in the Italianlanguage, enter the following:installp -c -a -g -X -d /dev/cd0 http-server.html.it_IT

v For Solaris systems, enter the following command:pkgadd -d /cdrom/cdrom0/solaris -a /cdrom/cdrom0/solaris/pddefault package

where package, located in the /solaris directory, is one or more of thefollowing:

IBMHAlang Specifies IBM HTTP Server messages.

IBMHSlang Specifies IBM HTTP Server documentation.

IBMHSSlang Specifies IBM HTTP Server SSL messages.

IBMldilang Specifies IBM SecureWay Directorydocumentation.

IBMldmlang Specifies IBM SecureWay Directory messages.

db2mslang1 Specifies DB2 product messages.

and lang is the language file abbreviation.

For example, to install the IBM SecureWay Directory messages in theJapanese language, enter the following:pkgadd -d /cdrom/cdrom0/solaris -a /cdrom/cdrom0/solaris/pddefault IBMldmJa

2. Stop the IBM HTTP Server and IBM HTTP Administration daemons (orservices) if they are running. From the http_directory/bin directory, use thefollowing commands:apachectl stop

adminctl stop

Note: To view if the httpd process is running, enter the following command:ps -ef | grep -i http

If the httpd process exists, then issue the kill command as follows:kill -i http_process_id_(pid)

3. From the http_directory/bin directory, issue the setuplang command. Thisshell script modifies the httpd.conf and admin.conf files for the new language.Choose the desired language from the menu table.

4. Restart the HTTP servers by issuing the following commands:http_directory/bin/apachectl start

http_directory/bin/adminctl start


5. The servers should be running in your desired language. You can access theserver through a Web browser and verify that the screens are in the appropriatelanguage.

Uninstalling language support packagesTo uninstall language support packages, do the following:1. Change your directory to the location where the uninstall.jar file is located.

v For UNIX systems, enter the following:/opt/location

v For Windows systems, enter the following:C:\Program Files\location

where location is as follows:

PDBLP/pdlp_uninst Specifies the location of the language packagesfor Access Manager Base.

PDJrtLP/jrtlp_uninst Specifies the location of the language packagesfor Access Manager Java Runtime Environment.

PDWslLP/wsllp_uninst Specifies the location of the language packagesfor Access Manager Plug-in for Edge Server.

PDWpiLP/wpilp_uninst Specifies the location of the language packagesfor Access Manager Plug-in for Web Servers.

PDWpmLP/wpmlp_uninst Specifies the location of the language packagesfor Access Manager Web portal manager.

PDWebLP/weblp_uninst Specifies the location of the language packagesfor Access Manager WebSEAL.

PDWasLP/waslp_uninst Specifies the location of the language packagesfor Access Manager WebSphere ApplicationServer.

2. To uninstall the language support packages, run the uninstall.jar command asfollows:v On UNIX systems, enter the following:

jre_path/java -jar uninstall.jar

where jre_path is the path where the Java executable is located. If the Javaexecutable is in the path, you do not have to specify jre_path.

v On Windows systems, enter the following:jre_path\java -jar uninstall.jar

where jre_path is the path where the Java executable is located. If the Javaexecutable is in the path, you do not have to specify jre_path.

Locale environment variablesAs with most current operating systems, localized behavior is obtained byspecifying the desired locale. For Access Manager software, you set the LANGenvironment variable to the desired locale name as specified by POSIX, X/Open,or other open systems standards.

Note: If you are in a Windows environment, you can alternatively modify thelanguage setting in the Regional Settings of the Control Panel.


If you specify the LANG environment variable and modify the regional settings,the LANG environment variable overrides this regional setting.

As specified by open systems standards, other environment variables overrideLANG for some or all locale categories. These variables include the following:v LC_CTYPE

v LC_TIME

v LC_NUMERIC

v LC_MONETARY

v LC_COLLATE

v LC_MESSAGES

v LC_ALL

If any of the previous variables are set, you must remove their setting for theLANG variable to have full effect.

LANG variable and UNIX systems: Most UNIX systems use the LANG variableto specify the desired locale. Different UNIX operating systems, however, requiredifferent locale names to specify the same language. Be sure to use a value forLANG that is supported by the UNIX operating system that you are using.

You can obtain the locale names for your UNIX operating system by running thefollowing command:locale -a

LANG variable and Windows systems: Most PC operating systems do not usethe LANG environment variable. Access Manager software, however, can useLANG to determine the desired language on PC systems. To do so, set the LANGto the canonical locale name based on the ISO language or territory codes withouta code set suffix. For example:v fr is the locale for standard Frenchv ja is the locale for Japanesev pt_BR is the locale for Brazilian Portuguesev C is the locale for English in C locale

On Windows systems, if LANG is not set, Access Manager uses the currentselection in the Regional Settings object of the Windows Control Panel.

Using locale variants: Although Access Manager software currently provides onlyone translated version for each language, you can use a preferred locale variant,and Access Manager finds the corresponding language translation. For example,Access Manager provides one translation for French, but each of the followinglocale settings finds the appropriate translation:v fr is the locale name for standard Frenchv fr_FR is the locale name for French in Francev fr_CA is the locale name for French in Canadav fr_CH is the locale name for French in Switzerland

Message catalogsMessage catalogs are typically installed in a top-level /msg directory and each ofthese message catalogs is installed under a language-specific subdirectory asfollows:


v On UNIX systems:/opt/PolicyDirector/nls/msg/locale

v On Windows systems:install_dir/nls/msg/locale

Access Manager recognizes variations in UNIX locale names and is usually able tomap the specified value to the appropriate message catalog.

The NLSPATH variable is used to find the appropriate message catalog directory,as specified by open systems standards. For example, if the message catalogs are in/opt/PolicyDirector/nls/msg, the NLSPATH variable is set to the following:/opt/PolicyDirector/nls/msg/%L/%N.cat

The %L directive is expanded to the message catalog directory that most closelymatches the current user language selection, and %N.cat expands to the desiredmessage catalog.

If a message catalog is not found for the desired language, the English C messagecatalogs are used.

For example, suppose you specify the AIX locale for German in Switzerland asfollows:LANG=De_CH.IBM-850

The %L directive is expanded in the following order to locate the specified locale:1. de_CH

2. de

3. C

Because Access Manager does not provide a German in Switzerland languagepackage, de_CH is not found. If the Access Manager German language package isinstalled, de is used. Otherwise, the default locale C is used, causing text to bedisplayed in English.

Text encoding (code set) supportDifferent operating systems often encode text in different ways. For example, PCoperating systems use SJIS (code page 932) for Japanese text, but UNIX operatingsystems often use eucJP.

In addition, multiple locales can be provided for the same language so thatdifferent code sets can be used for the same language on the same machine. Thiscan cause problems when text is moved from system to system or betweendifferent locale environments.

Access Manager addresses these problems by using Unicode and UTF-8 (themulti-byte form of Unicode) as the internal canonical representation for text.

Message catalogs are encoded using UTF-8, and the text is converted to the localeencoding before being presented to the user. In this way, the same French messagecatalog files can be used to support a variety of Latin 1 code sets, such asISO8859-1, Microsoft 1252, IBM PC 850, and IBM MVS

™

1047.

UTF-8 is also used to achieve text interoperability across the Tivoli environment.For example, Common Object Request Broker Architecture (CORBA) strings are


transmitted as UTF-8 within the Tivoli environment. This enables remotemanagement within a heterogeneous network in which local text encoding canvary. For example, Japanese file names can be manipulated on Japanese PCendpoints from a desktop executing in the UNIX Japanese EUC locale.

Text interoperability across the secure domain is also achieved by storing strings asUTF-8 within the Tivoli object database. Strings are converted to the local encodingfor viewing and manipulation by applications that are executing on differentoperating system code sets.

Location of code set filesInteroperability across your secure domain depends on code set files, which areused to perform UTF-8 conversion and other types of encoding-specific textprocessing. These files are installed in the base_dir/nls/TIS subdirectory under thedirectory specified for binary files during installation.

For example, if binaries are installed in /opt/PolicyDirector, the code set files arein /opt/PolicyDirector/nls/TIS. The TISDIR variable, which points to thedirectory that contains the code set directory, is used to find the files. The value forthe TISDIR variable in this example is /usr/local/Tivoli/bin/generic.

Code set files providedAccess Manager provides the following code set files for Solaris, HP-UX, and AIXsystems.

Language code set Solaris HP-UX AIX

Latin 1 (Western European) ISO98591 ISO88591ROMAN8

ISO88591850

Latin 2 (Eastern European) ISO88592 ISO88592 ISO88592

Turkish ISO88599 ISO88599 ISO88599

Latin 4 (Baltic) ISO88594 921

Estonian ISO88591 922

Greek ISO88597 ISO88597 ISO88597

Cyrillic ISO88595 ISO88595 ISO88595

Arabic† ISO88596 ISO88596ARABIC8‡

ISO885961046

Hebrew† ISO88598 ISO88598 ISO88598856

Simplified Chinese EUCCNGB2312‡

EUCCNHP15CN‡

EUCCN936GBK‡

Traditional Chinese EUCTWCNS11643‡

950BIG5‡

EUCTW950BIG5‡

EUCTW950BIG5‡

Japanese EUCJP932SJIS‡

PCK‡

EUCJP932SJIS‡

EUCJP932

Korean EUCKR EUCKR5601‡

EUCKR

Thai† 874TIS620‡

874TIS620‡

874TIS620‡


Language code set Solaris HP-UX AIX† The code set is available, but the product does not fully support it.‡ Denotes an alias for real table.

Access Manager provides the following code set files for Windows systems.

Language Code Set Windows

Latin 1 (Western European) 1252

Latin 2 (Eastern European) 1250

Turkish 1254

Latin 4 (Baltic) 1257

Estonian

Greek 1253

Cyrillic 1251

Arabic‡ 1256

Hebrew‡ 1255

Chinese, Simplified 936

Chinese, Traditional 950

Japanese 932

Korean 949

Thai‡ 874† The code set is available, but the product does not fully support it.‡ Denotes an alias for real table.



Chapter 2. Configuring supported user registries for IBMTivoli Access Manager

This chapter describes how to set up a supported user registry for use with AccessManager. This step in the installation process is required prior to installing AccessManager systems in your secure domain (as specified in the “Installation process”on page 11). For system requirements for a specific user registry, see “Supporteduser registries” on page 6.

If you plan to use easy installation to install and configure the IBM SecureWayDirectory server, skip the instructions in this chapter and follow the “Easyinstallation process” on page 12.

This chapter includes the following main sections:v “Setting up Active Directory”v “Configuring Lotus Domino” on page 32v “LDAP server configuration overview” on page 33v “Configuring the IBM SecureWay Directory server” on page 34v “Configuring the iPlanet Directory Server” on page 39v “Configuring LiveContent DIRECTORY” on page 43v “Configuring z/OS or OS/390 security servers” on page 49

Setting up Active DirectoryTo set up Active Directory for Access Manager, you must perform the followingtasks in this order:1. Create an Active Directory domain.2. Join an Active Directory domain3. Create an Active Directory administrative user

After you set up an Active Directory domain for use with Access Manager, thenext step is to set up Access Manager systems in your secure domain. Forinstructions, see Chapter 7, “Installing IBM Tivoli Access Manager on Windows” onpage 125. Keep in mind that Active Directory does not require installation of theIBM SecureWay Directory client and e-fix patch. In addition, you must installAccess Manager components in the order specified in step 6 on page 14 of thenative installation process.

Active Directory considerationsIt is important to review the following information before configuring ActiveDirectory for Access Manager:v Access Manager can be configured in an Active Directory single domain or

multi-domain environment. For information about single domain ormulti-domain environments, see the Active Directory product documentation atthe following Web address:http://www.microsoft.com/windows2000/en/server/help/


v In a single-domain environment, the non-domain controller system needs to jointhe same domain where Access Manager is configured. In a multi-domainenvironment, the non-domain controller system needs to join the ActiveDirectory domain.

v You cannot use the easy installation batch files to install Access Manager.v This release supports security global group only.v To import an Active Directory user as a Access Manager user, use the Active

Directory user’s login name as the user ID for the Access Manager user.v If you installed and configured Access Manager on a client of Active Directory

(for example, Access Manager and Active Directory are on different systems), theclient system must join the domain and you must sign on to the domain as theAdministrator to perform Access Manager configuration on the client system.

v The DNS in the network TCP/IP setting on the client system must be the sameas the domain controller’s network TCP/IP setting. You can use the root domaincontroller as the DNS server or you can use a separate DNS.

v If you configured Access Manager in the single domain, and the domain is thenon-root domain, you must run adschema_update.exe manually on the rootdomain controller.

Creating an Active Directory domainUse the Active Directory configuration wizard to promote your Windows 2000server system to a domain controller. The act of creating a domain controller alsocreates an Active Directory domain.

Before you begin, you must decide if you want to create a domain controller for anew domain or create an additional domain controller for an existing domain. Ifyou plan to create a domain controller for a new domain, you must also answerwhether or not this new domain will be one of the following:v The first domain in a new forestv The first domain in a new domain tree in an existing forestv A child domain in an existing domain tree

Note: If the new domain name does not exist in Forward Lookup Zones in DNS, itmust be created as a new zone before configuring a new domain controller.For more information about domain controllers, domain trees, and forests,consult your Windows 2000 server documentation.

To create a domain or add an additional domain controller to an existing domain,follow these steps:v “Joining an Active Directory domain”v “Creating an Active Directory administrative user” on page 31

Joining an Active Directory domainAfter you create an Active Directory domain, use the following procedure to join aWindows 2000 system to the Active Directory domain.

Note that to add a system to the domain, you must be logged on as anadministrator to the local system and have a valid user name and password to jointhe system to a domain. In addition, before adding a system to the domain, makesure that the client system and the server system are in the same DNS.

To join a Windows 2000 system to an Active Directory domain, follow these steps:


1. Right-click My Computer and then click Properties from the pop-up dialog.The System Properties notebook is displayed.

2. Click the Network Identification tab as shown:

3. Do one of the following:v Click Properties. Under Member of, click Domain and then type the name

of the domain that you want to join and click OK. You are prompted for auser name and password to join the system to the domain. To close theSystem Properties dialog, click OK. Restart your system for changes to takeeffect.

v To use the Network Identification wizard to join a domain, click NetworkID, click Next, and then continue with steps 4 through 14.

4. If you selected Network ID, the Network Identification Wizard dialog isdisplayed:

Chapter 2. Configuring supported user registries for IBM Tivoli Access Manager 27

5. Click Next to start the configuration. The Connecting to the Network dialog isdisplayed:

6. To join a domain, select This computer is part of a business network, and Iuse it to connect to other computers at work and then click Next. TheConnecting to the Network dialog is displayed:


7. Select My company uses a network with a domain and then click Next. TheNetwork Information dialog is displayed:

8. Click Next. The User Account and Domain Information dialog is displayed:

9. Type in the user name, password, and name of the domain that contains theuser account and then click Next. The Computer Domain dialog is displayed:


10. Type the computer domain name and then click Next. Note that you shouldnot add a .com extension on the computer domain name. The Domain UserName and Password dialog is displayed:

11. Type Administrator in the User name field with its associated password andthen click Next. The User Account dialog is displayed:

12. Type Administrator in the User name field and then click Next. The AccessLevel dialog is displayed:

13. Select Other, type Administrators in the associated field, and then click Next.


14. After the Network Identification Wizard has completed successfully, clickFinish to close the wizard and restart your system.

You can now log in to the Active Directory domain.

Creating an Active Directory administrative userTo create an Active Directory administrative user for Access Manager initialization,follow these steps:1. On the Active Directory server system, select Start → Programs →

Administrative Tools → Active Directory Users and Computers.2. Create a new user and add this new user to the groups of Administrators,

Domain Admins, Enterprise Admins and Schema Admins. This user is anActive Directory user only, not an Access Manager user. You can select anyname as the user login name, except sec_master, which is reserved for theAccess Manager administrator.

Active Directory replicationWhen a domain controller writes a change to its local copy of the Active Directory,a timer is started that determines when the domain controller’s replication partnersshould be notified of the change. By default, this interval is 300 seconds (5minutes). When this interval elapses, the domain controller initiates a notificationto each intra-site replication partner that it has changes that need to be propagated.Another configurable parameter determines the number of seconds to pausebetween notifications. This parameter prevents simultaneous replies by thereplication partners. By default, this interval is 30 seconds. Both of these intervalscan be modified by editing the registry.

To modify the delay between the change to the Active Directory and firstreplication partner notification, use the Registry Editor to modify value data for theReplicator notify pause after modify (secs) DWORD value in the followingregistry key:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

The default value data for the Replicator notify pause after modify (secs)DWORD value is 0x12c, which in hexadecimal format is 300 decimal (5 minutes).


To modify the notification delay between domain controllers, use the RegistryEditor to modify value data for the Replicator notify pause between DSAs (secs)DWORD value in the following registry key:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

The default value data for the Replicator notify pause between DSAs (secs)DWORD value is 0x1e, which in hexadecimal format is 30 decimal (30 seconds).

Note: You must stop the policy server before editing the registry and then restartthe system afterwards.

During Active Directory multi-domain configuration, a data propagation delayoccurs with a default value of 5 minutes. A user or group, which was just createdin non-root domains, might not be visible when user list or group list commandsare issued. Similarly, a user or group, newly created in the primary root domaincontroller, might not be immediately visible in the secondary root domain. Byadjusting the values of Replicator notify pause after modify and Replicator notifypause between DSAs in the Windows 2000 system registry, you can change thebehavior to best fit into your environment needs.

Attention: Using Registry Editor incorrectly can cause serious problems thatmight require you to reinstall your operating system.

Configuring Lotus DominoTo configure a Domino™ server as a user registry for Access Manager, you mustinstall a Lotus Notes® client on the Domino server. The Domino server must alsohave the Lightweight Directory Access Protocol (LDAP) interface enabled. This isrequired so that Access Manager can authenticate users using their Internetpassword. For information about system requirements, see “Supported userregistries” on page 6.

Access Manager using a Domino user registry is supported on Windows platformsonly. This is because Access Manager requires the Notes client, which is onlyavailable on supported Windows platforms. Because LDAP communication isrequired, each Access Manager system also requires that the IBM SecureWayDirectory client be installed on your system.

The IBM SecureWay Directory client is used to perform remote authentication tothe Domino LDAP server to verify user name and password information. TheNotes client is used for direct access to the domain (using a pre-defined privilegedaccount) for all other tasks, such as viewing and updating user information.

To install a Notes client on the Domino server, follow these steps:1. Run the Notes client setup file on the Notes/Domino CD for Windows

platforms.2. In the Notes Installation Options window, select Typical to install the Notes

client only. For detailed information about the Notes client installation, see theLotus Notes Installation Guide.

3. When the installation is complete, launch the Notes client to performconfiguration.

4. Select the Connect to a Domino Server radio button.5. Select the Network connection (via LAN) radio button.


6. Enter the fully qualified Domino server name. For example, enter thefollowing:domino1/Tivoli

7. Select the Use my name as identification option radio button and enter theAccess Manager administrative user ID (for example, AMDaemons). If youprovide the ID file, select the User ID was supplied to you in a file check boxand put the ID file in the c:\lotus\notes\data directory.

8. Click OK to continue. If you are prompted for additional configurationinformation, you can simply accept all the default values. Click Finish tocontinue the Notes client configuration steps.

9. If appropriate, select the Do not connect to an internet proxy server radiobutton.A password prompt window appears when the Notes client can access theremote Domino server.

10. Enter the password for the Access Manager administrative user. If thepassword is correct, the Notes client continues to finish the remainingconfiguration.When configuration is complete, the Notes ID file for the administrative useris installed in the Notes installation directory on the local system.

LDAP server configuration overviewThe following sections describe how to configure supported LDAP registries forIBM Tivoli Access Manager. LDAP registries are as follows:v “Configuring the IBM SecureWay Directory server” on page 34v “Configuring the iPlanet Directory Server” on page 39v “Configuring LiveContent DIRECTORY” on page 43v “Configuring z/OS or OS/390 security servers” on page 49

Data is stored within the LDAP server in a hierarchical tree structure called thedirectory information tree (DIT). The top of the tree is called a suffix (also referredto as a naming context or root). An LDAP server can contain multiple suffixes toorganize the data tree into logical branches or organizational units.

The following sections show you how to create Access Manager suffixes for yourparticular LDAP server. During the configuration process, Access Managerautomatically attempts to add appropriate access control lists (ACLs) to everysuffix that currently exists in the LDAP server. This is necessary to give AccessManager needed permission to manage users and groups defined within thosesuffixes. If you add suffixes after the initial configuration of Access Manager, youmust add the appropriate ACLs manually. For more information, see the IBM TivoliAccess Manager Base Administrator’s Guide.

Access Manager requires that you create a suffix named secAuthority=Default,which maintains Access Manager metadata. You must add this suffix onlyonce—when you first configure the LDAP server. This suffix enables AccessManager to easily locate and manage the data. It also secures access to the data,thus avoiding integrity or corruption problems.

Additionally, you are prompted for a Global Sign-On (GSO) distinguished name(DN) during configuration of the policy server. To store GSO metadata, you caneither create a suffix or specify the distinguished name of an existing LDAP DITlocation. You can store the GSO metadata anywhere you choose within the LDAP


DIT, but the location must already exist. If you decide to create a suffix, you mightconsider storing both GSO metadata and your user definitions in a single suffix.For instance, the following sections use o=tivoli,c=us as an example to store bothGSO metadata and user definitions. Note that you can also create additionalsuffixes to maintain user and group definitions.

After you create suffixes, you also must create directory entries for each suffix.This is necessary to instantiate the suffix. Otherwise, Access Manager is unable toattach ACLs when it is being configured. ACLs give Access Manager neededpermission to manage users and groups defined within those suffixes.

Note: For complete instructions about creating suffixes, see the productdocumentation shipped with your particular LDAP server. The followinginstructions serve as a general guide to creating suffixes. It is recommendedthat you create suffixes that mirror your organizational structure.

Configuring the IBM SecureWay Directory serverTo configure the IBM SecureWay Directory server for Access Manager, follow thesesteps:1. Ensure that the IBM SecureWay Directory server is installed.2. Using a Web browser, access the IBM SecureWay Directory server Web

administration tool at the following address:http://servername:port/ldap/index.htmlwhere servername is the name of the LDAP server and port is the port numberlisted in the httpd.conf file.

Note: It is important to note that both WebSEAL and the IBM HTTP Serveruse a default port of 80. It is recommended that you change the IBMHTTP Server port number to 8080 so that your Web server does notinterfere with port 80.

To change the default port number on your system, edit the httpd.conffile on your system and change the port number as shown:# Port: The port the standalone listens to.Port 8080

The httpd.conf file is located in one of the following directories:v On AIX systems:

/usr/HTTPServer/conf/httpd.conf

v On Solaris systems:/opt/IBMHTTPD/conf/httpd.conf

v On Windows systems:http_installation_dir/conf/httpd.conf

After you change the default port number on your system, restart theIBM HTTP Server as follows:v On AIX systems, enter the following:

/usr/HTTPServer/bin/apachectl restart

v On Solaris systems, enter the following:/opt/IBMHTTPD/bin/apachectl restart

v On Windows systems, go to the services panel. Click Stop and thenclick Start to restart the IBM HTTP Server.


3. Type the name and password of the LDAP administrator and then click Logonas shown:

The IBM SecureWay Directory Server Administration Web page is displayed.4. To ensure that the IBM SecureWay Directory server is started, click the arrow

to the left of Current state in the navigation pane and then click Server status.A window similar to the following is displayed:

5. If your server is stopped, click Start/Stop and then click Start to start theserver. A message is displayed when the server successfully starts or stops.

6. To create a suffix, select Settings → Suffixes from the left navigation pane. TheSuffixes frame is displayed.

7. To create the suffix where Access Manager maintains its metadata, type thefollowing required suffix as shown:secAuthority=Default

Note: The suffix distinguished name is not case-sensitive.8. Click Update. The Suffixes frame is displayed. Your new suffixes are

displayed in the Current server suffixes table.9. If you chose to create a suffix for the GSO metadata, type the new suffix

distinguished name in the Suffix DN field. For example, you might


type o=tivoli,c=us as shown:

You are prompted for the GSO suffix when you configure Access Managercomponents. For information about why a GSO suffix is required, see “LDAPserver configuration overview” on page 33.

10. Click Update. The Suffixes frame is displayed again. At this point, you cancreate additional suffixes to maintain user and group definitions.

Note: For more information about how to add suffixes, click the Help icon inthe upper-right portion of the window.

11. When you have finished adding suffixes, click restart the server in themessage in the upper portion of the frame as shown:

The following message is displayed after a few minutes:The directory server is running.

If the message fails to display, select Start → Settings → Control Panel and clickServices. Select the IBM SecureWay Directory service and click Start to restartthe LDAP server.

12. Do one of the following:


v If you did not add any suffixes other than secAuthority=Default, skip steps13 through 19. A directory entry for secAuthority=Default is automaticallyadded when the policy server is configured.

v If you added suffixes other than secAuthority=Default, continue to step 13to create directory entries for each suffix.

13. To create directory entries, enter dmt from a command prompt to start thedirectory management tool (DMT). The following window is displayed:

14. Click Add server in the bottom portion of the frame. A window similar to thefollowing is displayed:

15. Do one of the following:v If you want to use Secure Sockets Layer (SSL) between the DMT and the

LDAP server, follow these steps:a. Select Simple in the Authentication type field.b. In the Server name field, type your LDAP server name, for example,

dliburd2.tivoli.com. You can use either the IP address or the domainname.

c. In the User DN field, type the LDAP administrator ID used to connectto the server, for example:


cn=root

d. In the User password field, type the LDAP administrator password.e. Select the Use SSL check box.f. In the Port field, enter the SSL port number.g. Complete the Keyclass file name and the Keyclass file password fields.

The certificate name is optional based on how you set up the LDAPserver and the kdb file.

h. Click OK.v If you do not want to use SSL between the DMT and the LDAP server,

follow these steps:a. Select Simple in the Authentication type field.b. In the Server name field, type your LDAP server name, for example,

dliburd2.tivoli.com. You can use either the IP address or the domainname.

c. In the User DN field, type the LDAP administrator ID used to connectto the server, for example:cn=root

d. In the User password field, type the LDAP administrator password.e. Click OK.

16. Select Browse Tree from the left frame. Warning messages are displayedindicating that the suffixes that you created do not contain data. Click OK todismiss these messages. A window similar to the following is displayed:

17. Select the host name in the list on the right and click Add. For example, thehost name is ldap://dliburd2.tivoli.com:389 in the previous example.

18. In the Add an LDAP Entry window, complete the fields and click OK. Forexample, if you are adding a directory entry for the GSO suffix, a window


similar to the following is displayed:

19. Enter values for the attributes and then click Add. For example, the GSOsuffix example appears as shown:

20. When you have completed adding directory entries for the suffixes youcreated, click Exit to close the IBM SecureWay Directory Management Toolwindow.

Configuring the iPlanet Directory ServerBefore you begin, ensure that you have completed the basic server installation andconfiguration as described in the iPlanet Directory Server product documentation.For more information, see the iPlanet Directory Server documentation at thefollowing Web address:

http://docs.iplanet.com/docs/manuals/directory.html

To configure iPlanet Directory Server for Access Manager, follow these steps:1. To ensure that the directory server daemon (slapd-serverID) and the

administration server daemon (admin-serv) are running, do one of thefollowing:v On UNIX systems, enter the following commands:

/usr/iplanet/servers/slapd-serverID/start-slapd

/usr/iplanet/servers/start-admin

v On Window systems, select Start → Settings → Control Panel and then clickthe Services icon. Select the iPlanet Administration Server 5.0 and iPlanetDirectory Server 5 services and then click Start.

2. To start the iPlanet Console, enter one of the following:v On UNIX systems, enter the following:


% /usr/iplanet/servers/startconsole

v On Windows systems, select Start → Programs → iPlanet Server Products ->iPlanet Console 5.0.

The iPlanet Console Login window is displayed unless your configurationdirectory (o=NetscapeRoot directory) is stored in a separate instance of iPlanetDirectory Server. In this case, a window is displayed requesting youradministrator user ID, password, and the Web address of the administrativeserver for that directory server.

3. Log in using the user ID and password for the LDAP administrator. Forexample, type cn=Directory Manager and the appropriate password as shown:

The iPlanet console is displayed.4. From the Topology tab, click the Directory Server icon. The iPlanet Directory

Server console is displayed.5. From the iPlanet Directory Server console, select the Configuration tab.6. Right-click Data in the left navigation panel and then select New Root Suffix.

You can also create a new suffix by selecting Data and then selecting Object →Suffix from the menu bar as shown:

A pop-up window is displayed prompting you for the new suffix and adatabase name.

7. To create the suffix that maintains Access Manager data, typesecAuthority=Default in the New suffix field. Then type a unique name for


the new database and click OK as shown:

Note: The Create associated database automatically check box is preselected.This is necessary so that a database is created at the same time as thenew root suffix. The new root suffix is disabled until you create adatabase.

8. If you chose to create a suffix to maintain GSO data, type the suffixdistinguished name in the New suffix field and enter a unique databasename. For example, you might type o=tivoli,c=us and then click OK asshown:

You are prompted for the GSO suffix when you configure Access Manager.For more information about GSO, see “LDAP server configuration overview”on page 33.

9. Do one of the following:v If you did not add any suffixes other than secAuthority=Default, skip steps

10 through 13. A directory entry for secAuthority=Default is automaticallyadded when the policy server is configured.

v If you added suffixes other than secAuthority=Default, continue to step 10to create directory entries for each suffix.

10. Click the Directory tab and highlight the name of the server in the top of theleft pane.


11. Select Objects → New Root Object. A list of new suffixes for which no entryyet exists is displayed as shown:

12. For each new suffix (other than secAuthority=Default), select the new suffix.The New Object pane is displayed. Scroll down to find the entry type thatcorresponds to the suffix you are creating. For example, you might selectorganization for a suffix named o=tivoli,c=us. Highlight the entry type andclick OK as shown:

13. From the Property Editor window, enter a value for the entry. For theo=tivoli,c=us example, enter tivoli as the value for organization and then


click OK as shown:

14. After you have created entries for each suffix that you added, select Console →Exit to close the console.

Configuring LiveContent DIRECTORYBefore you begin, ensure that you have completed the basic server installation andconfiguration as described in the LiveContent DIRECTORY productdocumentation.

This section includes the following topics:v Loading the IBM Tivoli Access Manager schema file

– Adding object and attribute type definitions– Updating LiveContent DIRECTORY search suffixes

v Configuring the LiveContent DIRECTORY DAP portv Configuring the IBM Tivoli Access Manager host system

– Obtaining files from LiveContent DIRECTORY– Configuring and verifying bindings

v Updating LiveContent DIRECTORY DAC schemas

Note: Instructions assume familiarity with configuring and administering theLiveContent DIRECTORY.

To configure LiveContent DIRECTORY for Access Manager, follow these steps:1. Use the iCon Directory Management tool to create a directory (DSA) if one

does not already exist. For instructions, see the LiveContent DIRECTORYmanual.

2. Access Manager assumes that the LDAP port is one greater than the DAP port.If not, use the I500_DAP-PORT environment variable to set the DAP port.

3. Use the iCon server to verify the existence of an organization entry in the DIT.If an organization entry does not exist, use the Directory Administration Center(DAC) utility to create one.The DAC utility can be installed on any Windows NT system on the network.For instructions about using the DAC utility, see the LiveContent DIRECTORYmanual.


Loading the IBM Tivoli Access Manager schema fileTo load the Access Manager schema file, complete the following sections:v Adding object and attribute type definitionsv Updating LiveContent DIRECTORY search suffixes

Adding object and attribute type definitionsUse the iCon tool to load the Access Manager schema files and configuration files.The files are located in the following directory:/opt/PolicyDirector/i500/lib

To add object and attribute type definitions, follow these steps:1. Use a text editor to display the contents of the Access Manager file

pd_i500_attributes.cfg.2. Using the iCon tool, click Schema and then cut and paste the contents of the

pd_i500_attributes.cfg file into the New attributes in LDAP v3 format fieldas shown:

3. Click Schema import. The schema file is imported as shown:

4. Select Schema → Utilities.5. Click Reload Schema.


6. Use a text editor to display the contents of the filepd_i500_objectclasses.cfg.

7. Cut and paste the contents of pd_i500_objectclasses.cfg into the iConwindow:Schema → schema import:New objectclasses in LDAP v3 format

8. Click Schema import.9. Display the contents of the file pd_i500_objectclasses_ext_1.cfg.

10. Click Schema and then cut and paste the contents ofpd_i500_objectclasses_ext_1.cfg into the New objectclasses in LDAP v3format window.

11. Click Schema import. The new object classes are imported as shown:

12. Display the contents of the file pd_i500_objectclasses_ext_2.cfg.13. Click Schema and then cut and paste the contents of

pd_i500_objectclasses_ext_2.cfg into the New objectclasses in LDAP v3format field.

14. Click Schema import.15. Select Schema → Utilities.16. Click Reload Schema.


17. Click Check schema and verify that the schema are consistent as shown:

The schema is now loaded.

Updating LiveContent DIRECTORY search suffixesYou must update the domain suffixes for Access Manager in the LiveContentDIRECTORY configuration file on the LiveContent DIRECTORY system.

To update LiveContent DIRECTORY search suffixes, follow these steps:1. At the bottom of the following file, locate the section labeled NamingContext:

install_dir/icon/dsaname/i500ldap/serverconfig.cfg

where install_dir indicates the LiveContent DIRECTORY installation directoryand the dsa_name directory refers to the current DSA being used.

2. Verify that this section already contains the c=country entry. For example:c=us

3. To create the suffix where Access Manager maintains its metadata, type thefollowing required suffix as shown:secAuthority=Default

Note: The suffix distinguished name is not case-sensitive.

For example, the NamingContext section of the current DSA serverconfig.cfgfile might appear similar to the following:[NamingContext]

c=us

secAuthority=Default

4. Use the iCon tool to stop and then restart your current LiveContentDIRECTORY for changes to take effect.

Configuring the LiveContent DIRECTORY DAP portTo determine the LiveContent DIRECTORY DAP port using the iCon tool, clickMain → dsa_name → Comms. A protocol list is displayed.v On UNIX systems, the DAP port is the port number listed against the DAP/DSP

protocol.v On Windows NT, the DAP port is the transport selector (TSEL) number listed

against the DAP/DSP protocol.


If the DAP port is one less than the LDAP port number displayed on this page,you do not have to do anything further. This is the default value determined byAccess Manager. Otherwise, do one of the following:v On UNIX systems, set the following environment parameter:

I500_DAP_PORT=DAP_port

v On Windows NT systems, from the Start menu, select Settings → Control Paneland then click the System icon. From the Systems Properties dialog, click theEnvironment tab. In the Variable field, enter i500_DAP_PORT; in the Value field,enter DAP_port, and then click OK.

Configuring the IBM Tivoli Access Manager host systemTo configure the Access Manager host system, complete the following sections:v Obtaining files from LiveContent DIRECTORYv Configuring and verifying bindings

Obtaining files from LiveContent DIRECTORYThe Access Manager system requires specific files installed with LiveContentDIRECTORY. If Access Manager is running on the same system as the LiveContentDIRECTORY, these files are already present. However, if Access Manager andLiveContent DIRECTORY are running on separate systems, you must copy thesefiles from the LiveContent DIRECTORY system to the Access Manager system. Todo so, follow these steps:1. On the Access Manager system, create a directory in which to place required

LiveContent DIRECTORY files.2. Set the environment variable ODSRELEASE to the directory you created in step

1. For example, enter the following:export ODSRELEASE=install_directory

3. Create the necessary subdirectories:v bin

v scripts

v perl/bin

4. Ensure that $ODSRELEASE/bin and $ODSRELEASE/perl/bin are in the system path.This enables the utilities odsdua and perl to be executed.

Note: If your system has other versions of Perl, be sure that$ODSRELEASE/perl/bin is in the system path before any other directoriesthat contain a Perl binary.

5. Copy the following files from the LiveContent DIRECTORY system toappropriate subdirectories on the Access Manager system:v $ODSRELEASE/bin/odsdua

v $ODSRELEASE/scripts/dslib

v $ODSRELEASE/scripts/dulib

v $ODSRELEASE/scripts/oids

v $ODSRELEASE/perl (if not already in the path)6. Copy the $ODSRELEASE/dsa_name/oidslocal file from the LiveContent

DIRECTORY system to the $ODSRELEASE/scripts directory on the AccessManager system.

Note that Access Manager supports the LiveContent DIRECTORY on Solaris andWindows NT platforms. If Access Manager is running on Windows NT, you cannot


copy binaries from a Solaris system to the Windows system. Instead, you mustobtain the binaries from a Windows NT system that has LiveContent DIRECTORYinstalled.

If you do not have another Windows NT system on which to install theLiveContent DIRECTORY, you must install LiveContent DIRECTORY on the AccessManager Windows NT system, solely for the purpose of obtaining the necessaryfiles.

Configuring and verifying bindings1. Change to the /opt/PolicyDirector/i500/bin directory.2. To set up the name bindings for the security schema objects, enter the following

command:perl secschema -D manager_dn -w password -h i500_host-p LDAP_port -P DAP_port

3. To set up the name bindings for the GSO schema objects, enter the followingcommand:perl gsoschema -D manager_dn -w password -h i500_host-p LDAP_ port -P DAP_port

4. Start the iCon tool to reload the schema and verify that the Perl scriptscorrectly updated the schema.

5. Select Schema → Utilities.6. Click Reload Schema.7. Verify that the secAuthority, secUser, and eGSOuser bindings exist in the

schema as shown:

Updating LiveContent DIRECTORY DAC schemasLiveContent DIRECTORY maintains several copies of the schema file that containsobject type definitions and attribute type definitions. The following maintain acopy of the schema:v LiveContent DIRECTORYv The LDAP serverv The Directory Administration Center (DAC) utility


To use the DAC utility with the Access Manager schema, the DAC’s own schemadefinition files need to be updated. The required files are supplied in the AccessManager i500/lib directory.

To synchronize the files, you must append data from several Access Manager filesto the appropriate LiveContent DIRECTORY files. You can open each AccessManager file, copy the contents, and paste them into the specified LiveContentDIRECTORY file.

The Access Manager files are in the i500/lib directory, located in the AccessManager installation directory. For example, on a Solaris system, the directory is asfollows:/opt/PolicyDirector/i500/lib

The LiveContent DIRECTORY files are located in the i500DAC directory, located inthe LiveContent DIRECTORY DAC client installation directory.

To copy the contents of each Access Manager lib file to the correct LiveContentDIRECTORY DAC file, follow these steps:1. Append the contents of i500/lib/attfile to the end of the following file:

DAC_installation_directory/i500DAC/attfile

2. Append the contents of i500/lib/Etypes to the end of the following file:DAC_installation_directory/i500DAC/Etypes

3. Use the DAC utility to connect to the i500 server.4. Verify that the secAuthority entry is in the tree and has the correct creation

date and time as shown:

Configuring z/OS or OS/390 security serversThis section describes the configuration steps necessary to prepare the LDAPserver on z/OS or OS/390 for Access Manager. Particular emphasis is given toconfiguring Access Manager against a native security authorization facility (SAF)user registry.

These guidelines assume a new LDAP server instance dedicated to the AccessManager user registry. For more information, consult the OS/390 SecureWaySecurity Server LDAP and z/OS SecureWay Security Server LDAP product


documentation. For system requirements and applicable program temporary fixes(PTFs), see “Supported user registries” on page 6.

This chapter includes the following sections. Sample configuration files are alsoprovided.v Creating a DB2 database for the TDBM backendv Creating an LDAP configuration file for a TDBM backendv Starting the serverv Updating and loading schema filesv Enabling LDAP replicationv Configuring IBM Tivoli Access Manager for LDAP

Creating a DB2 database for the TDBM backendTo create a DB2 database for the TDBM backend, follow instructions in the READMEfile located in the following directory of your LDAP installation:/usr/lpp/ldap/examples/sample_server

Steps are as follows:1. Bind the Call Level Interface (CLI). The CLI provides an abstraction layer to

SQL commands. This step establishes the environment needed for the LDAPserver to use the CLI. The sample server provides a job file to bind the CLI. Anadministrator must move the file to an MVS® partition before it is possible toexecute the job. See “Sample CLI bind batch job” on page 207 for a copy of thisfile.

2. Create a CLI initialization file. The initialization file provides the LDAP server afacility and the data source for the CLI. An example of this file is found withthe sample server. It is referred to in the LDAP configuration file. See “SampleCLI initialization file” on page 209 for a copy of this file.

3. Create a new database. Use SQL Processor Using File Input (SPUFI) scripts torun with DB2 Interactive (DB2 I) on OS/390 to perform SQL commands. Tocreate a new database and associated tablespaces, run the SPUFI file located in“Sample DB2 database and tablespace script for SPUFI” on page 200. To createthe indexes for the new database, run the SPUFI file located in “Sample DB2index script for SPUFI” on page 205. Note that to execute a SPUFI script, youmust invoke DB2 I and select SPUFI from the Primary Option Menu.

Creating an LDAP configuration file for a TDBM backendTo create an LDAP configuration file for a TDBM backend, use the sampleconfiguration file in “Sample LDAP configuration” on page 199. The followingentries are required for a TDBM:

database TDBM GLDBTDBMSpecifies the database type and library name. This entry marks thebeginning of the TDBM section for the configuration file.

databasename dbnameSpecifies the name of the DB2 database used for the backend. It is specifiedin the CREATE DATABASE option of the SPUFI used to create thedatabase and tablespaces. See step 3 on page 50.

dsnaoini datasetSpecifies the DB2 initialization file. See step 2 for details about creating thisfile. The value of this option is of the form USERID.FILENAME.


dbuserid useridSpecifies the OS/390 user that owns the DB2 tables. The userid is the sameas the administrator who ran the SPUFI scripts (per step 2 on page 50).

servername stringSpecifies the name of the DB2 server location that manages the tables forthe LDAP server. The string is the value specified in the DATA SOURCEstanza of the CLI initialization file.

attrOverflowSize num_of_bytesSpecifies the size at which the entries of attributes are loaded in separateDB2 tables. Choose a value such that large binary data is stored in theseparate table space.

suffix dn_suffixSpecifies the root of a subtree in the name space managed by this serverwithin this backend. Include both the organization suffix DN for your userregistry and the secAuthority=Default, which specifies the DN for theAccess Manager security registry.

The following additional entries are required to make use of nativeauthentication. For detailed explanations about these entries, see theOS/390 LDAP Server Administration and Usage publication.

UseNativeAuth [SELECTED | ALL | OFF]The SELECTED option specifies that user entries with a value for theibm-nativeId attribute are authenticated against SAF. Choosing SELECTEDprovides the most flexibility and minimizes additional administrativeduties. The ALL option specifies that the SAF authentication is madeagainst the user name found in an entry’s UID attribute (if noibm-nativeId attribute is specified).

NativeAuthSubTree dn_suffixSpecifies the root of a subtree or trees in the name space for which nativeauthentication applies.

nativeAuthUpdateAllowed YESEnables Access Manager users to update their SAF passwords through theWeb-based pkmspasswd utility.

Starting the serverProvide the location of the configuration file created in “Configuring IBM TivoliAccess Manager for LDAP” on page 53. The LDAP server searches for and loads anumber of dynamic load libraries (DLLs) during its startup processing. The DLLsare located in a PDS file system. When starting slapd from the z/OS shell, thecorrect PDS must be referenced in the STEPLIB environment variable as follows:export STEPLIB=GLD.SGLDLNKexport PATH=$PATH:/usr/lpp/ldap/sbinGLDSLAPD -f slapd.conf

Updating and loading schema filesTo update and load schema files, you must first copy the following schema files toyour working directory:v schema.user.ldif

v schema.IBM.ldif

v upgrade3.7_ibm_schema390.def


The schema files contain the objects and attributes used to organize data for theAccess Manager services, as well as the SAF native authentication objectclass.

Modify each schema file to match the organization DN suffix in the LDAPconfiguration file. There is a single line describing the DN of the schema to beupdated.

Edit each file and change the following:dn: cn=schema, suffix

to (for example):dn: cn=schema,o=ibm,c=us

Load the files using the ldapmodify command as follows:ldapmodify -h hostname -p port -D bind_DN -w bind_pwd -f schema_file

Note: You must load schema.IBM.ldif followed by schema.user.ldif. It is notnecessary to reload the schema for each suffix DN configured.

Enabling LDAP replicationThis section describes how to enable LDAP replication. LDAP servers behave inthe master-slave model for replication tasks. The master server forwards directoryupdates to the slave. The slave, or replica server, can share the load for readrequests and act as a backup server.

By default, an LDAP server is configured to run as a master server. Providing themaster with an object detailing the location of one or more replica servers enablesreplication.

Adding a stanza to the replica LDAP server’s configuration fileTo add a stanza to the replica LDAP server’s configuration file, see the stanzaexample in “Sample LDAP configuration” on page 199. Required entries for areplica LDAP server are as follows:

masterServer ldapURLSpecifies the LDAP URL in the form ldap://server_name:port. This optionrefers to the FQDN and port of the master server.

masterServerDN DNSpecifies the DN that you provide the replicaBindDN in “Add an object tothe master LDAP server’s backend”.

masterServerPW stringSpecifies the password that you provide the replicaCredentials in “Addan object to the master LDAP server’s backend”.

Add an object to the master LDAP server’s backendAn example of a ldif file representing such an object is as follows:dn: cn=replicasobjectclass: replicaObjectcn: replicasreplicaHost: hostnamereplicaPort: portreplicaBindDn: any_unique_DN_to_bind_withreplicaCredentials: password_to_bind_withdescription:"Description Here"

This object can be loaded with an ldapmodify command as follows:


ldapmodify -h hostname -p port -D bind_DN -w bind_pwd -f schema_file

Configuring IBM Tivoli Access Manager for LDAPThe procedure to configure Access Manager servers for LDAP on OS/390 is thesame as the directory on any other platform.

To use native authentication, you must turn off auth-using-compare. To do so, editthe [ldap] stanza of the iv.conf file and change the line as follows:auth-using-compare = no

By default, authentications to LDAP are made with a compare operation, ratherthan a bind.

Access Manager supports LDAP failover and load-balancing for read operations.Access Manager read operations include authentication requests and queries forGSO data. If you configured a replica server (see “Enabling LDAP replication” onpage 52), you can provide the replica host name to Access Manager inthe ldap.conf file.

Native authentication user administrationThe majority of administrative tasks remain unchanged with the addition of nativeauthentication. Operations such as user create, user show, adding a user to an ACLentry or group, and all user modify commands (except password) work the sameas Access Manager configured against a standard LDAP registry. Users can changetheir own SAF passwords with the Web-based pkmspasswd utility.

Native authentication provides the added feature of many-to-one mapping ofAccess Manager users to SAF user IDs. Multiple users can have the sameibm-nativeId, and all bind with the same password. For this reason, it might beprudent to prevent many-to-one mapped users from changing the SAF password(lest users inadvertently lock their peers out of their accounts).pdadmin> group modify SAFusers add user1pdadmin> acl create deny_pkmspdadmin> acl modify deny_pkms set group user1 Tpdadmin> acl attach /Webseal/server_name/pkmspasswd deny_pkms

OS/390 LDAP native authentication bind does not provide the authority toperform a password reset. For example, with native authentication enabled, thefollowing Access Manager administration command does not work:pdadmin> user modify user1 password ChangeMe1

Furthermore, there is no out-of-the-box administration command to set theibm-nativeId entry for a user. To that end, the following instructions assist themanagement of Access Manager users with an associated nativeId.

The user create command does not change:pdadmin> user create user1 cn=user1,o=ibm,c=us user1 user1 ChangeMe1pdadmin> user modify user1 account-valid yes

The password (ChangeMe1, in this example) is set to the user’s userpassword entryin LDAP, which has no effect with native authentication enabled. In production,consider making this password something long and difficult to guess—in casenative authentication is ever inadvertently disabled.

To set the ibm-nativeId entry for a user, create a ldif file similar to the following:


cn=user1,o=ibm,c=usobjectclass=inetOrgPersonobjectclass=ibm-nativeAuthenticationibm-nativeId=SAF_username

You can load the ldif file using the ldapmodify command as follows:ldapmodify -h hostname -p port -D bind_DN -w bind_pwd -f schema_file

The SAF command to reset a user’s password is as follows:subsystem_prefix ALTUSER userid PASSWORD password


Chapter 3. Installing IBM Tivoli Access Manager on AIX

This chapter provides information about installing and configuring IBM TivoliAccess Manager (Access Manager) components on AIX systems. Instructions areprovided for both easy and native installation methods. Before you begin, makesure that you review the installation process on page 11 and are familiar withconfiguration decisions that you need to make during installation.

This chapter includes the following main sections:v “Using easy installation”v “Using native installation” on page 65v “Uninstalling IBM Tivoli Access Manager” on page 74

Using easy installationThis section describes how to install Access Manager using the easy installationmethod. This method is recommended if you are creating a secure domain oradding systems or components to an existing one. Before you begin, make surethat you review the installation process on page 12 and are familiar withconfiguration decisions that you need to make during installation.

Note: If you plan to configure Active Directory or Domino as your user registry,you cannot use easy installation.

Installation is performed through the use of shell scripts. These scripts make it easyfor you to install Access Manager by automatically installing software prerequisitesat the same time. They also let you know which components are currently installedand prompt you for configuration information. After you supply the necessaryconfiguration options, the script installs and configures the components withoutfurther intervention. And if you ever need to install these components again, youcan use the associated response file that is generated when you run an easyinstallation script. The response file automatically stores the configurationinformation that you entered. For more information about response files, see“Using response files” on page 61.

Easy installation considerationsBefore you begin using the easy installation process, review the followinginstallation considerations:v Ensure that you have installed all software prerequisites and meet requirements

listed in “Software requirements” on page 5.v If you want to view the status and messages in a language other than English

(default), you must install your language pack first. For instructions, see“Enabling language support” on page 15.

v You must install and configure only one policy server for each secure domain.v When using ezinstall_pdmgr to install the policy server, it is not necessary to

also run the ezinstall_pdrte script. The runtime component is installed withthe policy server component. Run the ezinstall_pdrte script only if you wantto set up a separate Access Manager runtime system.

v The ezinstall_ldap_server script adds required suffixes and necessary directoryentries to the directory information tree (DIT) for the IBM SecureWay Directory


server. However, depending on your organizational requirements, you mightdecide to create additional suffixes for user and group definitions. For moreinformation, see “LDAP server configuration overview” on page 33.

v If you plan to install Web portal manager, ensure that you review “AccessManager Web portal manager” on page 9. Also, keep in mind that IBM HTTPServer is installed with WebSphere. If you plan to install a Web server other thanIBM HTTP, do not use easy installation to install Web portal manager.

v The Access Manager runtime component cannot be configured until the policyserver is installed. If the runtime is already configured, you must unconfigure it,install the policy server, and then configure both packages.

Easy installation scriptsThe following easy installation scripts (except ezinstall_pdwpm) are located in theroot directory on the IBM Tivoli Access Manager Base for AIX, Version 3.9. The Webportal manager script, ezinstall_pdwpm, is located on the IBM Tivoli Access ManagerWeb Portal Manager for AIX, Version 3.9 CD.

Use these files to set up Access Manager systems or to add components to existingones. For example, you might run ezinstall_ldap_server to set up an IBMSecureWay Directory server system and then run ezinstall_pdmgr on a differentsystem to install the policy server. Or, you might run both scripts to install andconfigure these components on the same system.

Easy installation scripts detect when required products are installed and do notattempt to reinstall them. For example, if you run ezinstall_pdmgr on a systemthat is already set up using ezinstall_ldap_server, it does not reinstall GSKit orthe IBM SecureWay Directory client.

Note: For descriptions of information that you are prompted for duringconfiguration, see“Easy installation configuration options” on page 57. For astep-by-step example with illustrations, see Appendix C, “Easy installationscenarios” on page 211.

ezinstall_ldap_server (IBM SecureWay Directory server)Sets up a system in a secure domain with the following softwarepackages:v IBM DB2 Universal Database Editionv IBM Global Security Toolkit (GSKit)v IBM HTTP Serverv IBM SecureWay Directory clientv IBM SecureWay Directory server

ezinstall_pdrte (runtime)Sets up a system in a secure domain with the following softwarepackages:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory clientv Access Manager runtime

ezinstall_pdmgr (policy server)Sets up a system in a secure domain with the following softwarepackages:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory client


v Access Manager runtimev Policy server

ezinstall_pdacld (authorization server)Sets up a system in a secure domain with the following softwarepackages:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory clientv Access Manager runtimev Authorization server

ezinstall_pdauthadk (ADK)Sets up a system in a secure domain with the following softwarepackages:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory clientv Access Manager runtimev ADK

ezinstall_pdwpm (Web portal manager)Sets up a system with the following software packages:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory clientv Access Manager runtimev IBM WebSphere Application Server with FixPackv IBM HTTP Serverv Web portal manager

Easy installation configuration optionsThis section lists configuration information that is required during the easyinstallation process. It is recommended that you identify these values before youare prompted during installation. If you are planning to enable Secure SocketsLayer (SSL), configuration options are also provided.

Note that the configuration information for the policy server is used forconfiguring other Access Manager components. You are not prompted forconfiguration options for GSKit, the IBM SecureWay Directory client, the ADK, andthe Web portal manager components.

IBM SecureWay Directory serverDuring the configuration of the IBM SecureWay Directory server on an AIXsystem, you are prompted for the following information:

IBM HTTP Server configuration options are as follows:v Administration ID—Specifies the administrator ID. The default is root.v Administration password—Specifies the administrator ID password.v HTTP port—Specifies the port number used by IBM HTTP Server. It is

important to note that both WebSEAL and the IBM HTTP Server use a defaultport of 80. It is recommended that you change the IBM HTTP Server portnumber to 8080 so that your Web server does not interfere with port 80.

IBM SecureWay Directory server configuration options are as follows:

Chapter 3. Installing IBM Tivoli Access Manager on AIX 57

v LDAP Administrator ID (DN)—Specifies the distinguished name of the LDAPadministrator. The default name is cn=root.

v LDAP Administrator Password—Specifies the password associated with theLDAP administrator ID.

v LDAP DN for GSO Database—Specifies the distinguished name of where in theLDAP server directory information tree (DIT) that the Global Sign-On (GSO)database is located. For example:o=tivoli,c=us

For more information about the GSO suffix, see “LDAP server configurationoverview” on page 33.

v LDAP Server Port—Specifies the port number on which the LDAP serverlistens. The default port number is 389.

v Enable SSL between Access Manager and LDAP—Specifies whether SSLshould be enabled (yes or no). If yes is specified, the following information isrequested.– LDAP SSL Client Key File—Specifies the fully qualified path name where

the client GSKit key database file, pd_ldapkey.kdb, is located on the policyserver. This key file gets copied from the media\common directory to thefollowing directory:/var/ldap/keytab/pd_ldapkey.kdb

To enable SSL communication, you must manually copy this file from itslocation on the LDAP server to a directory on the policy server (andauthorization server if installed). Note that this key file is provided forevaluation use only.

– SSL Client Certificate Label (if required)—Specifies the label in the clientGSKit key database file of the client certificate to be sent to the server. Thislabel is required if the server is configured to require client authenticationduring SSL establishment. If you use the ezinstall_ldap_server script andthe default key file (pd_ldapkey.kdb), then the label for configuring the LDAPserver is PDLDAP. Typically, the LDAP server requires only server-sidecertificates that were specified during creation of the client .kbd file.

– SSL Key File Password—Specifies the password of the client GSKit keydatabase file. The pd_ldapkey.kdb file shipped with easy installation has adefault password of gsk4ikm. These defaults are usable if you install andconfigure the IBM SecureWay Directory server using theezinstall_ldap_server script. If you decide to change this password usingthe gsk5ikm utility, you must recall this default password.

– LDAP Server SSL Port—Specifies the port number on which the LDAPserver listens for SSL requests. The default port number is 636.

Access Manager runtimeDuring the configuration of the Access Manager runtime on an AIX system, youare prompted for the following information:v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP

server. For example:ldapserver.tivoli.com


If the Access Manager policy server is not installed on the same system as theAccess Manager runtime, you are also prompted for the following information:


v Policy Server Hostname—Specifies the fully qualified host name of the policyserver. For example:pdmgr.tivoli.com

v SSL Server Port— Specifies the port number on which the policy server listensfor SSL requests. The default port number is 7135.

v Access Manager CA Certificate Filename—If you specified to enable automaticdownloading of the CA certificate file (pdcacert.b64) during the configuration ofthe Access Manager policy server, leave this option blank. It is not needed whenconfiguring the Access Manager runtime environment.If you do not select to enable automatic downloading of the CA certificate file,you must manually copy the /var/PolicyDirector/keytab/pdcacert.b64 filefrom the policy server system locally to a directory on the runtime system.

Policy serverDuring the configuration of the policy server on an AIX system, you are promptedfor the following information:v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP






To enable SSL communication, you must manually copy this file from itslocation on the LDAP server to a directory on the policy server. Note that thiskey file is for evaluation use only.

– SSL Client Certificate Label (if required)—Specifies the label in the clientGSKit key database file of the client certificate to be sent to the server. Thislabel is required if the server is configured to require client authenticationduring SSL establishment. If you use the ezinstall_ldap_server script andthe default key file (pd_ldapkey.kdb), then the label should be left blank.Typically, the LDAP server requires only server-side certificates that werespecified during creation of the client .kbd file. In addition, if the SSL clientkey file label is not required, leave this field blank when configuring thepolicy server.






v SSL Server Port for Policy Server—Specifies the port number on which thepolicy server listens for SSL requests. The default port number is 7135.

v Policy Server SSL Certificate Lifetime— Specifies the number of days that theSSL certificate file is valid. The default number of days is 365.

v Enable Download of Certificates—Specify yes to enable automatic downloadingof the SSL certificate authority file during configuration of the policy server. Ifyou specify no, the SSL certificate authority file is placed in the followingdirectory:/var/PolicyDirector/keytab/pdcacert.b64

The pdcacert.b64 file must be copied to each Access Manager runtime clientsystem.

Authorization serverDuring the configuration of the authorization server on an AIX system, you areprompted for the following information:v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP


v LDAP Server Port—Specifies the port number on which the LDAP server listensfor SSL requests. The default port number is 389.


the client GSKit key database file is located on the policy server (default ismedia/common/pd_ldapkey.kdb). This file is placed in the following directory:/var/ldap/keytab/pd_ldapkey.kdb

To enable SSL with the LDAP server, you must copy this file from its locationon the LDAP server to the authorization server. Note that this key file is forevaluation use only.

– SSL Client Certificate Label (if required)—Specifies the label in the clientGSKit key database file of the client certificate to be sent to the server. Thislabel is required if the server is configured to require client authenticationduring SSL establishment. If you use the ezinstall_ldap_server script andthe default key file (pd_ldapkey.kdb), then the label for configuring the LDAPserver should be PDLDAP. Typically, the LDAP server requires onlyserver-side certificates that were specified during creation of the client .kbdfile.

Note: If the SSL client key file label is not required, leave this field blankwhen configuring the authorization server.

– SSL Key File Password—Specifies the password of the client GSKit keydatabase file. The pd_ldapkey.kdb file shipped with easy installation has adefault password of gsk4ikm. These defaults are usable if you install and


configure the IBM SecureWay Directory server using theezinstall_ldap_server script. If you decide to change this password usingthe gsk5ikm utility, you must recall this default password.




v Security Master Password—Specifies the password associated with thesec_master primary administrator ID.

Using response filesAccess Manager allows you to create response files to streamline the installationand configuration of Access Manager. A response file is a text file that contains theproduct and system information needed to install and configure components. It isuseful for performing unattended (silent) installations. The installation processreads the information from the response file instead of prompting you to fill in theblanks. You can also reuse a response file for future installations, using a texteditor to add components or to customize options.

This section includes the following sections:v “Creating a response file”v “Installing components using a response file”v “Response file example” on page 62v “Response file stanza-keyword options” on page 63

Note: Considerations for response files are the same as those for easy installation.

Creating a response fileYou can create a response file from scratch using any text editor, or you can useeasy installation scripts to automatically generate response files based on theresponses that you supply during installation.

The response file is named based on the package that you installed and configured.For example, if you run the ezinstall_pdrte script, the response file that isgenerated is named ezinstall_pdrte.rsp. Response files for each package that yourun are stored in the /var/tmp directory.

Response files enable you to set up the following on AIX systems:v IBM SecureWay Directory serverv Access Manager runtimev Policy serverv Authorization serverv ADKv Web portal manager

Installing components using a response fileTo use a response file to install Access Manager components, follow these basicsteps:1. Edit the response file to check its syntax and to ensure that the information is

accurate. For descriptions of the stanzas in the response file, see “Response file


stanza-keyword options” on page 63. Note that you can supply actualpasswords for the values at this time, or wait until you are prompted forpasswords when ezinstall is run with the response file.

2. Run the easy installation script and specify the response file. For example, enterthe following:ezinstall_pdrte /var/tmp/ezinstall_pdrte.rsp

where /var/tmp/ezinstall_pdrte.rsp is the fully qualified name of theresponse file.

Response file exampleA response file contains stanzas of attribute=value pairs. A stanza starts with aline containing the stanza name in brackets, for example, [LDAPS], and ends eitherwhen another line begins with another stanza name in brackets or when the end ofthe file is reached. Each stanza contains zero or more attribute=value pairs. Astanza name cannot be repeated more than once in a response file. Comments canbe added to a response file by using the character # before the comment.

The following is an example of a response file generated from easy installationscripts. Note that easy installation pauses during configuration to allow you tospecify any missing values.

Note: The default key file password for the IBM SecureWay Directory client isgsk4ikm.

[HTTPD]http-admin-id = roothttp-admin-pwd = secrethttp-port = 80

[LDAPS]ldap-adminid = cn=rootldap-password = secretsuffix = o=tivoli,c=ushost = ldapserv.tivoli.comport = 389ldap-ssl-client-keyfile = /cdrom/common/pd_ldapkey.kdbldap-ssl-client-keyfile-pwd = gsk4ikmldap-label = PDLDAP

[PDRTE]ldap-or-domino = 1host = ldapserv.tivoli.comport = 389ldap-server-ssl-port = 636master-host = pdmgr.tivoli.compd-cacert =enable-ssl = Yssl-client-keyfile = /var/ldap/keytab/pd_ldapkey.kdbssl-keyfile-pwd = gsk4ikmssl-port = 7135

[PDMGR]ldap-adminid = cn=rootldap-password = secretssl-life = 365ssl-port = 7135sec-master-pwd = secretenable-cert-download = Yprompt-languages = N


Response file stanza-keyword optionsThe following table shows the various stanza-keyword options available for use ina response file. The stanza names are used for readability on UNIX platforms.

Stanza Name UNIX Keyword Description

[HTTPD] http-admin-id Specifies the administrator’s user name.The default is Administrator.

[HTTPD] http-admin-pwd Specifies the administrator’s password.

[HTTPD] http-port Specifies the port that HTTPD uses.

[LDAPS] ldap-adminid Specifies the LDAP administrator ID orDistinguished Name (DN). The defaultis cn=root.

[LDAPS] ldap-password Specifies the LDAP administratorpassword.

[LDAPS] host Specifies the LDAP server host name.The default is the host name of thesystem being configured.

[LDAPS] server-port Specifies the LDAP server non-SSL portnumber. The default port number is389.

[LDAPS] suffix Specifies the LDAP distinguished namefor the Global Sign On (GSO) database.For example, o=tivoli,c=us.

[LDAPS] ldap-ssl-client-keyfile Specifies the path to the LDAP SSL keyfile. The default is/common/pd_ldapkey.kdb which isshipped on the CD. If this file is used,the password of gsk4ikm and theserver-side label of PDLDAP arerequired.

[LDAPS] ldap-ssl-client-keyfile-pwd Specifies the password associated withthe key file. If using the default ofmedia/common/pd_ldapkey.kdb, thepassword is gsk4ikm.

[LDAPS] ldap-label Specifies the label associated with theSSL key file. If using the default ofmedia/common/pd_ldapkey.kdb, the labelis PDLDAP.

[PDMGR] ldap-adminid Specifies the LDAP administrator ID.The default is cn=root. This ID iscreated during the configuration of theLDAP server.

[PDMGR] ldap-password Specifies the LDAP administratorpassword.

[PDMGR] port Specifies the LDAP server non-SSL port.The default port number is 389.

[PDMGR] ssl-life Specifies the lifetime of the certificatefile (pdcacert.b64). The default is 365days.



[PDMGR] enable-cert-download Specifies to enable Access Managerruntime environments on other systemsto automatically download thecertificate file (pdcacert.b64). Validvalues are Y (enable) or N (disable).

[PDMGR] sec-master-pwd Specifies the security master password.

[PDRTE] ldap-or-domino Specifies the registry type. On UNIX,the only valid value is 1.

[PDRTE] host Specifies the host name of the LDAPserver.

[PDRTE] port Specifies the LDAP server non-SSL port.The default port number is 389.

[PDRTE] ldap-server-ssl-port Specifies the LDAP server SSL port. Thedefault port number is 636.

[PDRTE] ssl-port Specifies the policy server SSL port. Thedefault port number is 7135.

[PDRTE] master-host Specifies the host name of the policyserver.

[PDRTE] pd-cacert Specifies the path to the policy servercertificate file (pdcacert.b64). This isrequired if the policy server does notallow automatic downloading of the fileby the Access Manager runtimeenvironment clients.

[PDRTE] enable-ssl Specifies to enable SSL communicationwith the LDAP server. Valid values areY (enable) or N (disable).

[PDRTE] ssl-client-keyfile Specifies the path to the SSL key filefrom the LDAP server (required if SSLis enabled). This file must be manuallyobtained from the LDAP server system.

[PDRTE] ssl-keyfile-pwd Specifies the password associated withthe LDAP SSL client key file.

[PDRTE] ssl-cert-label Specifies the label associated with theLDAP SSL client key file ofclient-side-type key files. The default isblank (null). This value is used only ifSSL is enabled.

[PDRTE] Suffix Specifies the LDAP distinguished namefor the GSO database.

[PDACLD] ldap-adminid Specifies the LDAP administrator ID.The default is cn=root. This ID iscreated during the configuration of theLDAP server.

[PDACLD] ldap-password Specifies the LDAP administratorpassword.

[PDACLD] sec-master-pwd Specifies the security master password.This password is created during theconfiguration of the policy server.


Using native installationThis section includes information about how to install and configure AccessManager components using native operating system utilities. Unlike the automatedscripts used in easy installation, you must manually install each component andany necessary patches in the appropriate order. Before you begin, make sure thatyou review the installation process on page 13 and are familiar with configurationdecisions that you need to make during installation.

This section includes the following main topics:v “Native installation considerations”v “Installing the IBM Global Security Toolkit”v “Installing the IBM SecureWay Directory client” on page 66v “Installing and configuring IBM Tivoli Access Manager” on page 66v “Installing and configuring the Access Manager Java Runtime Environment” on

page 67v “Installing and configuring Web portal manager” on page 68v “Native installation configuration options” on page 71

Native installation considerationsBefore you begin using the native installation process, ensure that the followingconditions are met:v You must install and configure only one policy server for each secure domain.v If you are installing the policy server, you must install the runtime component

first. However, you must not configure the runtime component until the policyserver is installed.

v After configuring the policy server, you can install and configure theauthorization server, ADK, or both, to any system in the secure domain,including the system that hosts the policy server.

v If you are installing the runtime on a different host system than the policy serverand download certificate is not enabled for this policy server, you must obtain theSSL certificate file from the policy server system. To do this, use a file transferprogram, such as ftp, to place a copy of the file in a location of your choice. Onthe policy server, the following certificate file is provided for evaluation use:/var/PolicyDirector/keytab/pdcacert.b64

You should copy this file after installing the runtime component but beforeconfiguring it. In addition, you must have user and group ownership of ivmgr.

Installing the IBM Global Security ToolkitTo install GSKit on an AIX system, follow these steps:1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Base for AIX, Version 3.9 CD.3. At the command prompt, enter the following:

installp -c -a -g -X -d /dev/cd0 gskit.rte

4. For the iKeyman utility to run correctly, you must set the following AIXvariable:export JAVA_HOME=path

where path is the path where the Java runtime environment is installed.


After you install GSKit, no configuration is necessary.

Note that the iKeyman key management utility (gsk5ikm) is installed with theGSKit package. This enables you to create key databases, public-private key pairs,and certificate requests. For more information about gsk5ikm, see the Secure SocketsLayer Introduction and iKeyman User’s Guide.

Installing the IBM SecureWay Directory clientTo install the IBM SecureWay Directory client on an AIX system, follow these steps:1. Ensure that you have installed GSKit. For instructions, see “Installing the IBM

Global Security Toolkit” on page 65.2. Log in to the system as root.3. Insert the IBM Tivoli Access Manager Base for AIX, Version 3.9 CD.4. At the command prompt, enter the following:

installp -c -a -g -X -d /dev/cd0 ldap.clientldap.max_crypto_client

where /dev/cd0 is the installation directory.

After you install the IBM SecureWay Directory client, no configuration is necessary.

Installing and configuring IBM Tivoli Access ManagerYou must configure the runtime component before configuring any other package.For descriptions of configuration options you are prompted for, see “Nativeinstallation configuration options” on page 71.

To install Access Manager components, follow these steps:1. Log in to the system as root.2. To install Access Manager components, insert the IBM Tivoli Access Manager

Base for AIX, Version 3.9 CD.3. At the command prompt, enter the following:

installp -c -a -g -X -d /dev/cd0 package

where /dev/cd0 is the directory and package is one or more of the following:

PD.RTE Indicates the runtime environment.

PD.Mgr Indicates the policy server.

PD.AuthADK Indicates the ADK.

PD.Acld Indicates the authorization server.

PD.WPM Indicates the Web portal manager.

Note: Installing this component by itself does not install theWeb portal manager interface. Follow instructions in“Installing and configuring Web portal manager” onpage 68.

4. To start the Access Manager configuration utility, enter the following command:pdconfig

The Access Manager Setup Menu is displayed.


5. Type the menu number for Configure Package. The Access ManagerConfiguration Menu is displayed. The list of installed Access Managerpackages is displayed.

6. Select the component that you want to configure, one at a time.Depending on the component that you selected, you are prompted forconfiguration options. For assistance with these configuration options, see“Native installation configuration options” on page 71.

7. When a message appears indicating that the package has been successfullyconfigured, press Enter to configure another component or select the x optiontwice to close the configuration utility.

8. Optional: To install and configure the Access Manager Java RuntimeEnvironment, see “Installing and configuring the Access Manager Java RuntimeEnvironment”.

9. Optional: To install and configure the Web Portal Manager interface, see“Installing and configuring Web portal manager” on page 68.

Installing and configuring the Access Manager Java RuntimeEnvironment

To install and configure the Access Manager Java Runtime Environment, followthese steps:1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Base for AIX, Version 3.9 CD.3. To install the prerequisite JRE package for AIX, enter the following command:

installp -c -a -g -X -d /dev/cd0 Java131.rte

Note: For supported prerequisite JRE versions, see “Access Manager JavaRuntime Environment” on page 3.

4. Set the environmental variable path by entering the following:export PATH=$PATH:jre_path

5. To install the Access Manager Java Runtime Environment, enter the following:installp -c -a -g -X -d /dev/cd0 PD.JRTE

where /dev/cd0 is the directory where the JRE package is located.

The Choose Setup Language dialog is displayed.6. Select the language that you want to use for the installation and click OK.7. The Welcome screen is displayed. Click Next to continue.8. Read the license agreement and click Yes if you agree to the terms. The

Choose Destination Location dialog is displayed if you have not installed asupported runtime environment.

9. Accept the default destination directory or click Browse to select a path toanother directory on the local system. If the directory does not exist, you mustconfirm that you want the directory created or specify a directory that exists.

10. To start copying files to the destination folder, click Next. If you want toreview or change any settings, click Back.The Setup Status dialog is displayed.

11. When the runtime installation has completed, select Yes to restart yourcomputer.


12. To configure the Java Runtime Environment for use within the current JRE,change to the install_dir/sbin directory and then enter the followingcommand:pdjrtecfg -action config

Note: For more information about the pdjrtecfg command, see “pdjrtecfg” onpage 230.

Installing and configuring Web portal managerFollow these steps to install and configure the Web portal manager interface.

Note: For information about using Web portal manager, see IBM Tivoli AccessManager Administrator’s Guide.

1. Review “Web portal manager installation considerations”.2. Install the IBM Global Sign-on Toolkit (GSKit). See “Installing the IBM Global

Security Toolkit” on page 65.3. Install the IBM SecureWay Directory client. See “Installing the IBM SecureWay

Directory client” on page 66.4. Install the IBM WebSphere Application Server. See “Installing IBM WebSphere

Application Server” on page 69.5. Install IBM WebSphere Application Server, FixPack 2. See “Installing IBM

WebSphere Application Server FixPack 2” on page 70.6. Install and configure the Access Manager runtime component. See “Installing

and configuring IBM Tivoli Access Manager” on page 66.7. Install and configure the Web portal manager component. See “Installing and

configuring IBM Tivoli Access Manager” on page 66.

Note: The Access Manager runtime and Web portal manager components mustbe installed on the same system as the IBM WebSphere ApplicationServer.

8. To start the Web portal manager, enter the following in your Web browser:https://host_name/pdadmin

A secure connection dialog is displayed, along with the Web portal managerwelcome screen.

Web portal manager installation considerationsBefore you begin using the native installation process, ensure that the followingconditions are met:v Ensure the policy server is installed and configured before installing Web portal

manager. Web portal manager can be installed on the same system as the policyserver or on a separate system.

v There are two choices for installing WebSphere: typical and custom. Typicalinstallation is recommended and described in this section. If you choose custominstallation, you must perform one of the following:– Select InstallDB for the Database Type field.– Create a database for WebSphere.

For instructions on using custom installation, see the following Web site:

http://www.ibm.com/software/webservers/appserv/infocenter.htmlv If WebSphere and the LDAP server are configured on the same system, they

both use the IBM HTTP Server as the Web server. It is important to note that


both WebSEAL and the IBM HTTP Server use a default port of 80. It isrecommended that you change the IBM HTTP Server port number to 8080 sothat your Web server does not interfere with port 80. To change the default portnumber on your system, edit the /usr/HTTPServer/conf/httpd.conf file andchange the port number as shown:# Port: The port the standalone listens to.Port 8080

v If WebSphere and WebSEAL are configured on the same system, you mustchange the WebSEAL port number in the webseald.conf file. For moreinformation about this file, see the IBM Tivoli Access Manager WebSEALAdministrator’s Guide.

v The configuration process automatically configures the IBM WebSphereApplication Server for Secure Sockets Layer (SSL) support over the port number443. If you encounter any problems after configuration, it is recommended thatyou stop and restart the IBM HTTP Server. To restart the server, enter thefollowing:/usr/HTTPServer/bin/apachectl restart

v To enable SSL support between your browser and the IBM HTTP Server, AccessManager provides the following files for evaluation use only. Do not use thesefiles in your production environment. You must acquire your own certificate,and modify the IBM HTTP Server httpd.conf configuration file so that theserver can find the new location of the key file.

/var/PolicyDirector/keytab/pdwpm.kdbSpecifies the key database file. The path of the file is specified in thehttpd.conf file.

/var/PolicyDirector/keytab/pdwpm.sthSpecifies the file where the key database password is stored.

v During Web portal manager configuration, the IBM HTTP Server configurationfile, httpd.conf, is modified to enable SSL. As a result, the IBM HTTP Serveronly listens on port 443. After you restart the IBM HTTP Server, the correct URLfor accessing Web portal manager is as follows:https://hostname/delegate

orhttps://hostname/register

where hostname is the name of the host running the IBM HTTP Server.

Installing IBM WebSphere Application ServerTo install IBM WebSphere Application Server, follow these steps:1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Web Portal Manager for AIX, Version 3.9 CD.3. Ensure that the DISPLAY variable is set. For example, enter the following:

echo $DISPLAY

If the result is NULL, you must export the DISPLAY variable and set it to the hostname of your system followed by :0.0. For example, if you are working on asystem named cwyman, enter the following:DISPLAY=cwyman:0.0

export DISPLAY

4. From a command prompt, change to the usr/sys/inst.images/WebSpheredirectory on the drive where the CD is located and enter the following:


./install.sh

5. To use the graphical user interface to install WebSphere, skip to step 6. To use aresponse file (silent installation), run the install.sh script as follows and thenskip to “Installing IBM WebSphere Application Server FixPack 2”../install.sh -silent -responseFile ./install.script \-prereqfile ./prereq.properties

Note: Ensure that you view the screen during the installation process in caseyou are prompted for instructions or an error occurs.

6. To install IBM WebSphere Application Server using the GUI, run the install.shscript, located in the current directory as follows:./install.sh

The WebSphere Application Server, Advanced Single Server Edition v4.0window is displayed. Click Next to continue.

7. Select Typical installation (the default choice) and click Next.8. Default paths are displayed for the WebSphere Application Server destination

directory and IBM HTTP Server. If the system already has the IBM HTTPServer installed on it, this choice does not appear. Accept these defaults byselecting Next.It is a good idea to make a note of these paths as they are needed during theinstallation of the WebSphere Application Server FixPack 2. The default pathfor the application server is /usr/WebSphere/AppServer. The default path for theIBM HTTP Server is /usr/HTTPServer if it installed as part of the WebSphereinstallation. If the HTTP Server is installed as part of the Web portal managereasy installation, or as part of the Access Manager installation, the default pathis /usr/HTTPServer.

A dialog is displayed indicating your installation selections. Select Install tobegin the installation process.

Installing IBM WebSphere Application Server FixPack 2To install IBM WebSphere Application Server FixPack 2, follow these steps. Notethat for systems running in Simplified Chinese, German, and Italian, you mustinstall FixPack 3 instead of FixPack 2 as instructed. To download FixPack 3 forWebSphere Application Server, Advanced Single Server Edition, Version 4.0, see theSupport downloads link at the following Web site:

http://www.ibm.com/software/webservers/appserv/support.html1. Stop the WebSphere Application Server, HTTP Server, and the LDAP server (if

installed on the same system).2. Insert the IBM Tivoli Access Manager Web Portal Manager for AIX, Version 3.9

CD.3. From a command prompt, change to the ptf402 directory on the drive where

the CD is located.4. Copy the contents of the PTF402 directory into a temporary directory on your

system.5. Open a command prompt and change directories to this temporary directory.6. Run install.sh.7. When prompted, enter the directory where the IBM WebSphere Application

Server is installed and press Enter. The default directory is/usr/WebSphere/AppServer.

8. When prompted if you want to upgrade the IBM HTTP Server, select Yes.


9. When prompted, enter the directory where IBM HTTP Server is installed andpress Enter. The default directory is /usr/HTTPServer.The upgrade begins. A prompt displays the message Upgrading IBM JDK. Thisupgrade installs the IBM Developer Kit for AIX® in the WebSphere directory.There is not a conflict if you already have the toolkit installed elsewhere onyour system.When the upgrade is complete, a prompt displays the message Installationcompleted with no errors. Please view the activity log for details.Press any key to continue.

10. Press a key to continue.WebSphere Application Server 4.0 and FixPack 2 are now installed.

11. Restart your system.

Native installation configuration optionsThis section lists configuration information that is required during the nativeinstallation process. It is recommended that you identify these values before youare prompted during installation. If you are planning to enable Secure SocketsLayer (SSL), configuration options are also provided.

Note that the configuration information for the policy server is used forconfiguring other Access Manager components. You are not prompted forconfiguration options for GSKit, the IBM SecureWay Directory client, the ADK,Web portal manager, or Access Manager JRE components.

Access Manager runtimeDuring the configuration of the Access Manager runtime environment on an AIXsystem, you are prompted for the following information:v LDAP server hostname—Specifies the fully qualified host name of the LDAP


v LDAP server port number—Specifies the port number on which the LDAPserver listens. The default port number is 389.

If the Access Manager policy server is not installed on the same system as theAccess Manager runtime, you are also prompted for the following information:v Hostname of the Policy Server machine—Specifies the fully qualified host name

of the policy server. For example:pdmgr.tivoli.com

v SSL listening port used by Policy Server—Specifies the port number on whichthe policy server listens for SSL requests. The default port number is 7135.

Policy serverDuring the configuration of the policy server on an AIX system, you are promptedfor the following information:v LDAP administrative user DN—Specifies the distinguished name of the LDAP

administrator. The default name is cn=root.v LDAP administrative user password—Specifies the password associated with

the LDAP administrator ID.v Enable SSL communication between the Access Manager Policy Server and

the LDAP server—Specifies whether SSL should be enabled yes or no. If yes isspecified, the following information is requested.


– Location of the LDAP SSL client key file—Specifies the fully qualified pathname where the client GSKit key database file is located on the policy server.To enable SSL support between your policy server and LDAP server, theAccess Manager Base CD provides the following sample key file for evaluationuse only:/common/pd_ldapkey.kdb

This file is not intended for use in a production environment. To acquire yourown certificate, see information about creating a key database file andcertificate in Chapter 8, “Enabling Secure Sockets Layer for LDAP registries”on page 151.

– SSL client certificate label (if required)—Specifies the label in the clientGSKit key database file of the client certificate to be sent to the server. Thislabel is required if the server is configured to require client authenticationduring SSL establishment. If you use the ezinstall_ldap_server script andthe default key file (pd_ldapkey.kdb), then the label should be left blank.Typically, the LDAP server requires only server-side certificates that werespecified during creation of the client .kbd file. In addition, if the SSL clientkey file label is not required, leave this field blank when configuring thepolicy server.

– LDAP SSL client key file password—Specifies the password of the clientGSKit key database file. The pd_ldapkey.kdb file shipped with easyinstallation has a default password of gsk4ikm. These defaults are usable ifyou install and configure the IBM SecureWay Directory server using theezinstall_ldap_server script. If you decide to change this password usingthe gsk5ikm utility, you must recall this default password.

– LDAP server SSL port number—Specifies the port number on which theLDAP server listens for SSL requests. The default port number is 636.

v LDAP DN for GSO database—Specifies the distinguished name of where in theLDAP server directory information tree (DIT) that the Global Sign-On (GSO)database is located. For example:o=tivoli,c=us


v Access Manager Administrator password—Specifies the password associatedwith the sec_master primary administrator ID. You are prompted to re-enter thispassword for confirmation.

v SSL server port for Access Manager Policy Server—Specifies the port numberon which the policy server listens for SSL requests. The default port number is7135.

v Policy Server SSL certificate lifetime— Specifies the number of days that theSSL certificate file is valid. The default number of days is 365.

v Enable root CA Certificate download—Specify yes to enable automaticdownloading of the SSL certificate authority file. Regardless of whether youspecify yes or no, the SSL certificate authority file is placed in the followingdirectory:/var/PolicyDirector/keytab/pdcacert.b64

If this option is set to no, you must copy the pdcacert.b64 file on each AccessManager runtime system in your secure domain.


Authorization serverDuring the configuration of the authorization server on an AIX system, you areprompted for the following information:v LDAP administrative user DN —Specifies the distinguished name of the LDAP

administrator. The default name is cn=root.v LDAP administrator user password—Specifies the password associated with the

LDAP administrator ID.v Enable SSL communication between the Access Manager Policy Server and

the LDAP server—Specifies whether SSL should be enabled yes or no. If yes isspecified, the following information is requested.– Location of the LDAP SSL client key file—Specifies the fully qualified path

name where the client GSKit key database file is located on the policy server.To enable SSL support between your policy server and LDAP server, theAccess Manager Base CD provides the following sample key file for evaluationuse only:/common/pd_ldapkey.kdb


– SSL client certificate label (if required)—Specifies the label in the clientGSKit key database file of the client certificate to be sent to the server. Thislabel is required if the server is configured to require client authenticationduring SSL establishment. If you use the ezinstall_ldap_server script andthe default key file (pd_ldapkey.kdb), then the label for configuring the LDAPserver should be PDLDAP. Typically, the LDAP server requires onlyserver-side certificates that were specified during creation of the client .kbdfile.




v Password for the Access Manager Administrator—Specifies the passwordassociated with the sec_master primary administrator ID.

Default portsDefault port numbers are as follows:v LDAP server non-SSL port: 389v LDAP server SSL port: 636v Policy server SSL port: 7135


Uninstalling IBM Tivoli Access ManagerUninstalling Access Manager, Version 3.9 is a two-part process. You mustunconfigure components and then remove them, unless instructed to do otherwise,such as during the upgrade process.

This section includes the following topics:v “Uninstallation considerations”v “Unconfiguring IBM Tivoli Access Manager”v “Removing IBM Tivoli Access Manager” on page 75

Uninstallation considerationsBefore you begin the uninstall process, ensure that the following conditions aremet:v Stop all Access Manager services and applications before uninstalling

components.v Unconfigure and remove the policy server system last.v Unconfigure any other Access Manager applications, such as WebSEAL, before

unconfiguring the policy server and runtime components.v You do not have to unconfigure the ADK before removing it.

Unconfiguring IBM Tivoli Access ManagerBefore you remove Access Manager packages from a UNIX system, you mustunconfigure components. To do so, follow these steps:1. Log in as root.2. Change to the following directory:

cd /opt/PolicyDirector/bin

3. Start the Access Manager configuration utility:pdconfig

The Access Manager Setup Menu is displayed.4. Type the number of the menu item for the Access Manager component that you

want to unconfigure.5. Repeat this procedure for each package that you want to unconfigure.

If you are unconfiguring a server, a prompt is displayed requesting thedistinguished name and password of the LDAP administrative user.

Note: Unconfiguring the policy server removes all configuration andauthorization information from the secure domain. This includesinformation used by Access Manager applications, such as WebSEAL. Toproceed, enter y.

6. To unconfigure the Access Manager Java Runtime Environment, use thepdjrtecfg command. For example, enter the following to unconfigure the JREspecified by the jre_path variable:pdjrtecfg -action unconfig -java_home jre_path



Removing IBM Tivoli Access ManagerTo remove components from an AIX system, follow these steps:1. Ensure that the components are unconfigured. Follow the instructions in

“Unconfiguring IBM Tivoli Access Manager” on page 74.2. To remove one or more packages and any dependent software, enter the

following:installp -u -g package

where package is one of the following:

Note: Use the –g option only if you want dependent software for the specifiedpackage removed.

PD.AuthADK Indicates the ADK.

PD.Mgr Indicates the policy server.

PD.Acld Indicates the authorization server.

PD.RTE Indicates the runtime environment.

PDJ.rte Indicates the Java Runtime Environment.

PD.WPM Indicates the Web portal manager interface.

ldap.client Indicates the IBM SecureWay Directory client.

ldap.max_crypto_clientIndicates the highest level of encryption for the IBM SecureWayDirectory client.

gskit.rte Indicates GSKit.

A prompt is displayed indicating the preremove script is being run. Each file islisted as it is removed.



Chapter 4. Installing IBM Tivoli Access Manager on HP-UX

This chapter provides information about installing and configuring IBM TivoliAccess Manager (Access Manager) components on HP-UX systems. Instructions areprovided for both easy and native installation methods. Before you begin, makesure that you review the installation process on page 11 and are familiar withconfiguration decisions that you need to make during installation.


Using easy installationThis section describes how to install Access Manager, Version 3.9, using the easyinstallation method. This method is recommended if you are creating a securedomain or adding systems or components to an existing one.








v The Access Manager runtime component cannot be configured until the policyserver is installed. If the runtime is already configured, you must unconfigure it,install the policy server, and then configure both packages.


Easy installation scriptsThe following easy installation scripts are located in the root directory of the IBMTivoli Access Manager Base for HP-UX, Version 3.9 CD. Use these files to set upAccess Manager systems or to add components to existing ones.

For example, you might run ezinstall_pdacld to set up an authorization serversystem and then run ezinstall_pdmgr on a different system to install a separatepolicy server. Easy installation scripts detect when required products are installedand do not attempt to reinstall them. For example, if you run ezinstall_pdmgr ona system that is already set up using ezinstall_pdrte, it does not reinstall GSKitor the IBM SecureWay Directory client.

Note: For descriptions of information that you are prompted for duringconfiguration, see “Easy installation configuration options”. For anillustration of how to use easy installation scripts, see Appendix C, “Easyinstallation scenarios” on page 211.


ezinstall_pdmgr (policy server)Sets up a system in a secure domain with the following softwarepackages:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory clientv Access Manager runtimev Policy server





Note that the configuration information for the policy server is used forconfiguring other Access Manager components. You are not prompted forconfiguration options for GSKit, the IBM SecureWay Directory client, and the ADKcomponents.

Access Manager runtimeDuring the configuration of the Access Manager runtime on an HP-UX system, youare prompted for the following information:v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP



If the Access Manager policy server is not installed on the same system as theAccess Manager runtime, you are also prompted for the following information:v Policy Server Hostname—Specifies the fully qualified host name of the policy

server. For example:pdmgr.tivoli.com



Policy serverDuring the configuration of the policy server on an HP-UX system, you areprompted for the following information:v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP






To enable SSL with the LDAP server, you must copy this file from its locationon the LDAP server to the policy server system or authorization serversystem.

– SSL Client Certificate Label (if required)—Specifies the label in the clientGSKit key database file of the client certificate to be sent to the server. Thislabel is required if the server is configured to require client authentication

Chapter 4. Installing IBM Tivoli Access Manager on HP-UX 79

during SSL establishment. If you use the ezinstall_ldap_server script andthe default key file (pd_ldapkey.kdb), then the label should be left blank.Typically, the LDAP server requires only server-side certificates that werespecified during creation of the client .kbd file. In addition, if the SSL clientkey file label is not required, leave this field blank when configuring thepolicy server.









Authorization serverDuring the configuration of the authorization server on an HP-UX system, you areprompted for the following information:v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP















This section includes the following sections:v “Creating a response file”v “Installing components using a response file” on page 82v “Response file example” on page 82v “Response file stanza-keyword options” on page 83





Response files enable you to set up the following on HP-UX systems:v Access Manager runtimev Policy serverv Authorization serverv ADK


accurate. For descriptions of the stanzas in the response file, see “Response filestanza-keyword options” on page 83. Note that you can supply actualpasswords for the values at this time, or wait until you are prompted forpasswords when ezinstall is run with the response file.



Response file exampleA response file contains stanzas of attribute=value pairs. A stanza starts with aline containing the stanza name in brackets, for example, [PDRTE], and ends eitherwhen another line begins with another stanza name in brackets or when the end ofthe file is reached. Each stanza contains zero or more attribute=value pairs. Astanza name cannot be repeated more than once in a response file. Comments canbe added to a response file by using the character # before the comment.

The following is an example of a UNIX response file generated from easyinstallation scripts. Note that easy installation pauses during configuration to allowyou to specify any missing values.













[PDRTE] ldap-or-domino Specifies the registry type. The onlyvalid value is 1.

















Using native installationThis section includes information about how to install and configure AccessManager components using native operating system utilities. Unlike the automatedscripts used in easy installation, you must manually install each component andany necessary patches in the appropriate order.

This section includes the following main topics:v “Native installation considerations”v “Installing the IBM Global Security Toolkit” on page 85v “Installing the IBM SecureWay Directory client” on page 85v “Installing and configuring IBM Tivoli Access Manager” on page 86v “Installing and configuring the Access Manager Java Runtime Environment” on

page 67v “Native installation configuration options” on page 87

Native installation considerationsBefore you begin using the native installation process, ensure that the followingconditions are met:v You must install and configure only one policy server for each secure domain.v If you are installing the policy server, you must install the runtime environment

first. However, you must not configure the runtime environment until the policyserver is installed.





Installing the IBM Global Security ToolkitTo install GSKit on an HP-UX system, follow these steps:1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Base for HP-UX, Version 3.9 CD.3. Start pfs_mountd and then pfsd in the background, if they are not running.

Mount the CD with the pfs_mount command. For example, enter thefollowing:/usr/sbin/pfs_mount /dev/dsk/c0t0d0 /cd-rom

where /dev/dsk/c0t0d0 is the CD device and /cd-rom is the mount point.4. At the command prompt, enter the following:

swinstall -s /cd-rom/hp gsk5bas

where /cd-rom/hp is the directory.5. Ensure that you set and verify that the following path has been set in

your .profile:SHLIB_PATH=/usr/lib

To set this path, enter the following command:export SHLIB_PATH=/usr/lib;$SHLIB_PATH


Note that the SHLIB_PATH is only required to run the iKeyman key managementutility (gsk5ikm), which is installed with the GSKit package. This enables you tocreate key databases, public-private key pairs, and certificate requests. For moreinformation about gsk5ikm, see the Secure Sockets Layer Introduction and iKeymanUser’s Guide.

Installing the IBM SecureWay Directory clientTo install the IBM SecureWay Directory client on an HP-UX system, follow thesesteps:1. Ensure that you have installed GSKit. For instructions, see “Installing the IBM

Global Security Toolkit”.2. Log in to the system as root.3. Insert the IBM Tivoli Access Manager Base for HP-UX, Version 3.9 CD.4. Start pfs_mountd and then pfsd in the background, if they are not running.



swinstall -s /cd-rom/hp LDAP

where /cd-rom/hp is the directory and LDAP is the name of the IBM SecureWayDirectory client package.



Installing and configuring IBM Tivoli Access ManagerYou must configure the runtime environment before configuring any otherpackage. For descriptions of configuration options you are prompted for, see“Native installation configuration options” on page 87.

To install Access Manager on HP-UX, follow these steps:1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Base for HP-UX, Version 3.9 CD.3. Start pfs_mountd and then pfsd in the background, if they are not running.



swinstall -s /cd-rom/hp package

where /cd-rom/hp is the directory and package is one or more of the following:

PDRTE Indicates the runtime environment.

PDMgr Indicates the policy server.

PDAuthADK Indicates the ADK.

PDAcld Indicates the authorization server.5. Change to the following directory:


6. To start the Access Manager configuration utility, enter the followingcommand:pdconfig

The Access Manager Setup Menu is displayed.7. Type the menu number for Configure Package. The Access Manager

Configuration Menu is displayed. The list of installed Access Managerpackages is displayed.

8. Select the component that you want to configure, one at a time.Depending on the component that you selected, you are prompted forconfiguration options. For assistance with these configuration options, see“Native installation configuration options” on page 87.


10. Optional: To install and configure the Access Manager Java RuntimeEnvironment, see“Installing and the configuring Access Manager JavaRuntime Environment”.

Installing and the configuring Access Manager Java RuntimeEnvironment

To install and configure the Access Manager Java Runtime Environment, followthese steps:1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Base for HP-UX, Version 3.9 CD.


3. Start pfs_mountd and then pfsd in the background, if they are not running.Mount the CD with the pfs_mount command.

4. To install the prerequisite JRE for HP-UX, enter the following command:swinstall -s /cd-rom/hp rte_13101os11.depot B9789AA

where /cd-rom/hp is the directory.


5. Set the environmental variable path by entering the following:PATH=$PATH: java_path

6. To install the Access Manager Java Runtime Environment, enter the following:swinstall -s /cd-rom/hp pdjRTE

where /cd-rom/hp is the directory.









Note that the configuration information for the policy server is used forconfiguring other Access Manager components. You are not prompted forconfiguration options for GSKit, the IBM SecureWay Directory client, the ADK, orAccess Manager JRE components.

Access Manager runtimeDuring the configuration of the Access Manager runtime environment on anHP-UX system, you are prompted for the following information:


v LDAP server hostname—Specifies the fully qualified host name of the LDAPserver. For example:ldapserver.tivoli.com


If the Access Manager policy server is not installed on the same system as theAccess Manager runtime environment, you are also prompted for the followinginformation:v Hostname of Policy Server machine—Specifies the fully qualified host name of

the policy server. For example:pdmgr.tivoli.com

v SSL listening port used by Policy Server— Specifies the port number on whichthe policy server listens for SSL requests. The default port number is 7135.

Policy serverDuring the configuration of the policy server on an HP-UX system, you areprompted for the following information:v LDAP administrative user DN—Specifies the distinguished name of the LDAP



the LDAP server—Specifies whether SSL should be enabled (yes or no). If yes isspecified, the following information is requested.– Location of the LDAP SSL client key file—Specifies the fully qualified path



– SSL client certificate label (if required)—Specifies the label in the clientGSKit key database file of the client certificate to be sent to the server. Thislabel is required if the server is configured to require client authenticationduring SSL establishment. If you use the ezinstall_ldap_server script andthe default key file (pd_ldapkey.kdb), then the label should be left blank.Typically, the LDAP server requires only server-side certificates that werespecified during creation of the client .kbd file. In addition, if the SSL clientkey file label is not required, leave this field blank when configuring thepolicy server.










If this option is set to no, you must copy the pdcacert.b64 file to each AccessManager runtime system.

Authorization serverDuring the configuration of the authorization server on an HP-UX system, you areprompted for the following information:v LDAP administrative user DN—Specifies the distinguished name of the LDAP











v Password for the Access Manager Administrator—Specifies the passwordassociated with the sec_master primary administrator ID.


Uninstalling IBM Tivoli Access ManagerUninstalling Access Manager, Version 3.9 is a two-part process. You mustunconfigure components and then remove them, unless you are instructed to dootherwise, such as during the upgrade process.




unconfiguring the policy server and runtime environment.v You do not have to unconfigure the ADK before removing it.




The Access Manager Setup Menu is displayed.


4. Type the number of the menu item for the Access Manager component that youwant to unconfigure.

5. Repeat this procedure for each package that you want to unconfigure.If you are unconfiguring a server, a prompt is displayed requesting thedistinguished name and password of the LDAP administrative user.



Note: You cannot uninstall the Access Manager JRE using the Add/RemovePrograms icon similar to the other Access Manager components. Formore information about the pdjrtecfg command, see “pdjrtecfg” onpage 230.

Removing IBM Tivoli Access ManagerTo remove components from an HP-UX system, follow these steps:1. Ensure that the components are unconfigured. Follow the instructions in

“Unconfiguring IBM Tivoli Access Manager” on page 90.2. To remove one or more packages, enter the following:

swremove package

where package is one or more of the following:



PDAcld Indicates the authorization server.

PDRTE Indicates the runtime environment.

PDJrte Indicates the Java Runtime Environment.

LDAP Indicates the IBM SecureWay Directory client.

gsk5bas Indicates GSKit.




Chapter 5. Installing IBM Tivoli Access Manager on Linux

This chapter provides information about installing and configuring IBM TivoliAccess Manager (Access Manager) components on Linux systems. Instructions areprovided for both easy and native installation methods. Before you begin, makesure that you review the installation process on page 11 and are familiar withconfiguration decisions that you need to make during installation.








v You must install and configure only one policy server for each secure domain.v Do the following:

– Before running easy installation scripts, ensure that the ksh is installed, orcreate a soft link to the bash as shown:ln -s /bin/bash /bin/ksh

– Before installing components, remove the nss_ldap-149.1 package or otherconflicting LDAP packages, if installed.


v The Access Manager runtime component cannot be configured until the policyserver is installed. Note that the policy server is not supported on Linuxplatforms.

Easy installation scriptsThe following easy installation scripts are located in the root directory of the IBMTivoli Access Manager Base for Linux, Version 3.9 CD. Use these files to set up AccessManager systems or to add components to existing ones.

For example, you might run ezinstall_pdrte to set up a runtime environment andthen run ezinstall_pdauthadk on a different system to install a separateauthorization server. Or, you might run both scripts to install and configure thesecomponents on the same system. Easy installation scripts detect when requiredproducts are installed and do not attempt to reinstall them.

Note: For descriptions of information that you are prompted for duringconfiguration, see “Easy installation configuration options”. For anillustration of how to use easy installation scripts, see Appendix C, “Easyinstallation scenarios” on page 211.




Note that you are not prompted for configuration options for GSKit, the IBMSecureWay Directory client, and the ADK components.

Access Manager runtimeDuring the configuration of the Access Manager runtime on a Linux system, youare prompted for the following information:v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP




If the Access Manager policy server is not installed on the same system as theAccess Manager runtime, you are also prompted for the following information:v Policy Server Hostname—Specifies the fully qualified host name of the policy


v SSL Server Port—Specifies the port number on which the policy server listensfor SSL requests. The default port number is 7135.




Note: Considerations for response files are the same as those for easy installation.For more information, see “Easy installation considerations” on page 93.



Response files enable you to set up the following Linux systems:v Access Manager runtimev ADK


accurate. For descriptions of the stanzas in the response file, see “Response filestanza-keyword options” on page 96. Note that you can supply actual

Chapter 5. Installing IBM Tivoli Access Manager on Linux 95

passwords for the values at this time, or wait until you are prompted forpasswords when ezinstall is run with the response file.



Response file exampleA response file contains stanzas of attribute=value pairs. A stanza starts with aline containing the stanza name in brackets, for example, [PDRTE], and ends eitherwhen another line begins with another stanza name in brackets or when the end ofthe file is reached. Each stanza contains zero or more attribute=value pairs. Astanza name cannot be repeated more than once in a response file. Comments canbe added to a response file by using the character # before the comment.






[PDRTE] ldap-or-domino Specifies the registry type. The onlyvalid value is 1. .














Using native installationThis section includes information about how to install and configure AccessManager components using native operating system utilities. Unlike the automatedscripts used in easy installation, you must manually install each component andany necessary patches in the appropriate order.

This section includes the following main topics:v “Native installation considerations”v “Installing the IBM Global Security Toolkit” on page 98v “Installing the IBM SecureWay Directory client” on page 98v “Installing and configuring IBM Tivoli Access Manager” on page 98v “Access Manager runtime configuration options” on page 99v “Installing and the configuring Access Manager Java Runtime Environment” on

page 99

Native installation considerationsBefore you begin using the native installation process, ensure that the followingconditions are met:v If you are installing the runtime on a different host system than the policy server

and download certificate is not enabled for this policy server, you must obtain theSSL certificate file from the policy server system. To do this, use a file transferprogram, such as ftp, to place a copy of the file in a location of your choice. Onthe policy server, the following certificate file is available for evaluation use:/var/PolicyDirector/keytab/pdcacert.b64



Installing the IBM Global Security ToolkitTo install GSKit on a Linux system, follow these steps:1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Base for Linux, Version 3.9 CD.3. Change to the directory /mnt/cdrom/linux where /mnt/cdrom is the mount point

for your CD.4. To install GSKit in the default location, enter the following:

rpm -i gsk5bas-5.0.4.67.i386.rpm



Installing the IBM SecureWay Directory clientTo install the IBM SecureWay Directory client on a Linux system, follow thesesteps.

Note: Before installing the IBM SecureWay Directory client on a Linux system,remove the nss_ldap-149-1 package or other conflicting LDAP packages, ifinstalled.

1. Ensure that you have installed GSKit. For instructions, see “Installing the IBMGlobal Security Toolkit” on page 98.

2. Log in to the system as root.3. Insert the IBM Tivoli Access Manager Base for Linux, Version 3.9 CD.4. Change to the directory /mnt/cdrom/linux where /mnt/cdrom is the mount point

for your CD.5. To install the IBM SecureWay Directory client in the default location, enter the

following:rpm -i ldap-clientd-3.2-2-1.i386.rpm


Installing and configuring IBM Tivoli Access ManagerYou must configure the runtime environment before configuring any otherpackage. For descriptions of configuration options you are prompted for, see“Access Manager runtime configuration options” on page 99.

To install Access Manager components on Linux, follow these steps:1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Base for Linux, Version 3.9 CD.3. Change to the directory /mnt/cdrom/linux where /mnt/cdrom is the mount

point for your CD.4. To install components in the default location, enter the following:

rpm -i package

where package is one of the following:


PDRTE-PD-3.9.0-0.i386.rpmIndicates the runtime environment.

PDAuthADK-PD-3.9.0-0.i386.rpmIndicates the ADK.

5. Change to the following directory:cd /opt/PolicyDirector/bin

6. To start the Access Manager configuration utility, enter the followingcommand:pdconfig



8. Select the component that you want to configure, one at a time.If you are installing the runtime, you are prompted for configuration options.For assistance with these configuration options, see “Access Manager runtimeconfiguration options”.


10. Optional: To install and configure the Access Manager Java RuntimeEnvironment, see “Installing and the configuring Access Manager JavaRuntime Environment”.

Access Manager runtime configuration optionsDuring the configuration of the Access Manager runtime environment on a Linuxsystem, you are prompted for the following information. You are not prompted forconfiguration options for GSKit, the IBM SecureWay Directory client, the ADK,v LDAP server hostname—Specifies the fully qualified host name of the LDAP



v Hostname of the Policy Server—Specifies the fully qualified host name of thepolicy server. For example:pdmgr.tivoli.com

v SSL listening port used by Policy Server—Specifies the port number on whichthe policy server listens for SSL requests. The default port number is 7135.


1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Base for Linux, Version 3.9 CD.3. Change to the directory /mnt/cdrom/linux where /mnt/cdrom is the mount

point for your CD.4. To install the prerequisite JRE package for Linux, enter the following

command:rpm -i IBMJava2-JRE-1.3-10.0.i386.rpm



5. Set the environmental variable path by entering the following:export PATH=$PATH: jre_path

6. To install components in the default location, enter the following:rpm -i PDJrte-PD-3.9.0-0.i386.rpm








Uninstalling IBM Tivoli Access ManagerUninstalling Access Manager, Version 3.9 is a two-part process. You mustunconfigure components and then remove Access Manager packages.

This section includes the following topics:v “Uninstallation considerations”v “Unconfiguring IBM Tivoli Access Manager” on page 101v “Removing IBM Tivoli Access Manager” on page 101





Unconfiguring IBM Tivoli Access ManagerBefore you remove Access Manager packages from a Linux system, you mustunconfigure components. To do so, follow these steps:1. Log in as root.2. Change to the following directory:




want to unconfigure.5. Repeat this procedure for each package that you want to unconfigure.6. To unconfigure the Access Manager Java Runtime Environment, use the

pdjrtecfg command. For example, enter the following to unconfigure the JREspecified by the jre_path variable:pdjrtecfg -action unconfig -java_home jre_path


Removing IBM Tivoli Access ManagerTo remove components from a Linux system, follow these steps:1. Ensure that you have unconfigured components. Follow instructions in

“Unconfiguring IBM Tivoli Access Manager”.2. To remove one or more packages, enter the following:

rpm -e package


PDAuthADK-PD Indicates the ADK.

PDRTE-PD Indicates the runtime environment.

PDJrte-PD Indicates the Java Runtime Environment.

ldap_clientd Indicates the IBM SecureWay Directory client.

gsk5bas Indicates GSKit.

Package removal completes silently. The Linux command prompt returns uponsuccessful completion.

A message is displayed indicating that the removal of the software package wassuccessful.



Chapter 6. Installing IBM Tivoli Access Manager on Solaris

This chapter provides information about installing and configuring IBM TivoliAccess Manager (Access Manager) components on Solaris systems. Instructions areprovided for both easy and native installation methods. Before you begin, makesure that you review the installation process on page 11 and are familiar withconfiguration decisions that you need to make during installation.


Using easy installationThis section describes how to install Access Manager, Version 3.9, using the easyinstallation method. This method is recommended if you are creating a securedomain or adding systems or components to an existing one. Before you begin,make sure that you review the installation process on page 12 and are familiarwith configuration decisions that you need to make during installation.








v The ezinstall_ldap_server script adds required suffixes and necessary directoryentries to the directory information tree (DIT) for the IBM SecureWay Directory


server. However, depending on your organizational requirements, you mightdecide to create additional suffixes for user and group definitions. For moreinformation, see “LDAP server configuration overview” on page 33.

v If you plan to install Web portal manager, ensure that you review “Web portalmanager installation considerations” on page 116. Also, keep in mind that IBMHTTP Server is installed with WebSphere. If you plan to install a Web serverother than IBM HTTP, do not use easy installation to install Web portal manager.

v The Access Manager runtime component cannot be configured until the policyserver is installed. If the runtime environment is already configured, you mustunconfigure it, install the policy server, and then configure both packages.

Easy installation scriptsThe following easy installation scripts (except ezinstall_pdwpm) are located in theroot directory on the IBM Tivoli Access Manager Base for Solaris, Version 3.9. The Webportal manager script, ezinstall_pdwpm, is located on the IBM Tivoli Access ManagerWeb Portal Manager for Solaris, Version 3.9 CD.

Use these files to set up Access Manager systems or to add components to existingones. For example, you might run ezinstall_ldap_server to set up an LDAPserver system and then run ezinstall_pdmgr on a different system to install aseparate policy server. Or, you might run both scripts to install and configure thesecomponents on the same system.

Easy installation scripts detect when required products are installed and do notattempt to reinstall them. For example, if you run ezinstall_pdmgr on a systemthat is already set up using ezinstall_ldap_server, it does not reinstall GSKit, orthe IBM SecureWay Directory client.

Note: For descriptions of information that you are prompted for duringconfiguration, see “Easy installation configuration options” on page 105. Fora step-by-step example with illustrations, see Appendix C, “Easy installationscenarios” on page 211.

ezinstall_ldap_server (IBM SecureWay Directory server)Sets up a system in a secure domain with the following softwarepackages:v IBM DB2 Universal Database Editionv IBM Global Security Toolkit (GSKit)v IBM HTTP Serverv IBM SecureWay Directory clientv IBM SecureWay Directory server


ezinstall_pdmgr (policy server)Sets up a system in a secure domain with the following softwarepackages:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory client


v Access Manager runtimev Policy server



ezinstall_pdwpm (Web portal manager)Sets up a system with the following software packages:v GSKitv IBM SecureWay Directory clientv Access Manager runtimev IBM WebSphere Application Server with PTFv IBM HTTP Serverv Web portal manager



IBM SecureWay Directory serverDuring the configuration of the IBM SecureWay Directory server on a Solarissystem, you are prompted for the following information:

IBM HTTP Server configuration options are as follows:v Administration ID—Specifies the administrator ID. The default is root.v Administration password—Specifies the administrator ID password.v HTTP port—Specifies the port number used by IBM HTTP Server. It is

important to note that both WebSEAL and IBM HTTP Server use a default portof 80. It is recommended that you change the IBM HTTP Server port number to8080 so that your Web server does not interfere with port 80.

IBM SecureWay Directory server configuration options are as follows:

Chapter 6. Installing IBM Tivoli Access Manager on Solaris 105








To enable SSL communication, you must manually copy this file from itslocation on the LDAP server to a directory on the policy server (andauthorization server if installed).




Access Manager runtimeDuring the configuration of the Access Manager runtime on a Solaris system, youare prompted for the following information:v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP





v Policy Server Hostname—Specifies the fully qualified host name of the policyserver. For example:pdmgr.tivoli.com



Policy serverDuring the configuration of the policy server on a Solaris system, you areprompted for the following information:v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP







– SSL Client Certificate Label (if required)—Specifies the label in the clientGSKit key database file of the client certificate to be sent to the server. Thislabel is required if the server is configured to require client authenticationduring SSL establishment. If you use the ezinstall_ldap_server script andthe default key file (pd_ldapkey.kdb), then the label should be left blank.Typically, the LDAP server requires only server-side certificates that werespecified during creation of the client .kbd file. In addition, if the SSL clientkey file label is not required, leave this field blank when configuring thepolicy server.










Authorization serverDuring the configuration of the authorization server on a Solaris system, you areprompted for the following information:v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP







Note: If the SSL client key file label is not required, leave this field blankwhen configuring the policy server.

– SSL Key File Password—Specifies the password of the client GSKit keydatabase file. The pd_ldapkey.kdb file shipped with easy installation has adefault password of gsk4ikm. These defaults are usable if you install and


configure the IBM SecureWay Directory server using theezinstall_ldap_server script. If you decide to change this password usingthe gsk5ikm utility, you must recall this default password.










Response files enable you to set up the following Solaris systems:v IBM SecureWay Directory serverv Access Manager runtimev Policy serverv Authorization serverv ADKv Web portal manager


accurate. For descriptions of the stanzas in the response file, see “Response file


stanza-keyword options” on page 111. Note that you can supply actualpasswords for the values at this time, or wait until you are prompted forpasswords when ezinstall is run with the response file.



Response file exampleA response file contains stanzas of attribute=value pairs. A stanza starts with aline containing the stanza name in brackets, for example, [LDAPS], and ends eitherwhen another line begins with another stanza name in brackets or when the end ofthe file is reached. Each stanza contains zero or more attribute=value pairs. Astanza name cannot be repeated more than once in a response file. Comments canbe added to a response file by using the character # before the comment.



[HTTPD]http-admin-id = roothttp-admin-pwd = secrethttp-port = 80

[LDAPS]ldap-adminid = cn=rootldap-password = secretsuffix = o=tivoli,c=ushost = ldapserv.tivoli.comport = 389ldap-ssl-client-keyfile = /cdrom/common/pd_ldapkey.kdbldap-ssl-client-keyfile-pwd = gsk4ikmldap-label = PDLDAP






[HTTPD] http-admin-id Specifies the administrator’s user name.The default is Administrator.

[HTTPD] http-admin-pwd Specifies the administrator’s password.

[HTTPD] http-port Specifies the port that HTTPD uses.

[LDAPS] ldap-adminid Specifies the LDAP administrator ID orDistinguished Name (DN). The defaultis cn=root.

[LDAPS] ldap-password Specifies the LDAP administratorpassword.

[LDAPS] host Specifies the LDAP server hostname.The default is the hostname of thesystem being configured.

[LDAPS] server-port Specifies the LDAP server non-SSL portnumber. The default port number is389.

[LDAPS] suffix Specifies the LDAP distinguished namefor the Global Sign On (GSO) database.For example, o=tivoli,c=us.

[LDAPS] ldap-ssl-client-keyfile Specifies the path to the LDAP SSL keyfile. The default is/common/pd_ldapkey.kdb, which isshipped on the CD. If this file is used,the password of gsk4ikm and theserver-side label of PDLDAP arerequired.

[LDAPS] ldap-ssl-client-keyfile-pwd Specifies the password associated withthe key file. If using the default ofmedia/common/pd_ldapkey.kdb, thepassword is gsk4ikm.

[LDAPS] ldap-label Specifies the label associated with theSSL key file. If using the default ofmedia/common/pd_ldapkey.kdb, the labelis PDLDAP.









[PDRTE] ldap-or-domino Specifies the registry type. The onlyvalid value is 1.
















Using native installationThis section includes information about how to install and configure AccessManager components using native operating system utilities. Unlike the automatedscripts used in easy installation, you must manually install each component andany necessary patches. Before you begin, make sure that you review theinstallation process on page 13 and are familiar with configuration decisions thatyou need to make during installation.

This section includes the following topics:v “Native installation considerations”v “Installing the IBM Global Security Toolkit”v “Installing the IBM SecureWay Directory client” on page 114v “Installing and configuring IBM Tivoli Access Manager” on page 114v “Installing and the configuring Access Manager Java Runtime Environment” on


Native installation considerationsBefore you begin using the native installation process, ensure that the followingconditions are met:v You must install and configure only one policy server for each secure domain.v If you are installing the policy server, you must install the runtime environment

first. However, you must not configure the runtime environment until the policyserver is installed.




Installing the IBM Global Security ToolkitTo install GSKit on a Solaris system, follow these steps:1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Base for Solaris, Version 3.9 CD.3. Change to the /cdrom/cdrom0/solaris directory.4. To install the required GSKit file, enter the following:

pkgadd -d /cdrom/cdrom0/solaris -a /cdrom/cdrom0/solaris/pddefault gsk5bas

5. When the installation is completed, type q to return to the command prompt.




Installing the IBM SecureWay Directory clientTo install the IBM SecureWay Directory client on a Solaris system, follow thesesteps:1. Ensure that you have installed GSKit. For instructions, see “Installing the IBM

Global Security Toolkit” on page 113.2. Log in to the system as root.3. Insert the IBM Tivoli Access Manager Base for Solaris, Version 3.9 CD.4. Change to the /cdrom/cdrom0/solaris directory.5. To install the IBM SecureWay Directory client, enter the following:

pkgadd -d /cdrom/cdrom0/solaris -a /cdrom/cdrom0/solaris/pddefault IBMldapc

6. During installation, you are asked if you want to use /opt as the basedirectory. If space permits, use /opt as the base installation directory. To accept/opt as the base directory, press Enter.

7. When the installation is completed, type q to return to the command prompt.


Installing and configuring IBM Tivoli Access ManagerYou must configure the runtime environment before configuring any otherpackage. For descriptions of configuration options you are prompted for, see“Native installation configuration options” on page 119.

To install Access Manager components, follow these steps:1. Log in to the system as root.2. If you are not installing Access Manager from a remote file system, insert the

IBM Tivoli Access Manager Base for Solaris, Version 3.9 CD.3. To install Access Manager packages, enter the following command:

pkgadd -d /cdrom/cdrom0/solaris -a /cdrom/cdrom0/solaris/pddefault package

where -d /cdrom/cdrom0/solaris specifies the location of the package and -a/cdrom/cdrom0/solaris/pddefault specifies the location of the installationadministration script, either on the CD.

Installable packages are as follows. You must install one or more of thesepackages in the following order:

PDRTE Indicates the Access Manager runtime.




PDWPM Indicates the Web portal manager interface.

Note: Installing this component by itself does not install theWeb portal manager interface. Follow instructions in“Installing and configuring Web portal manager” onpage 116.


When the installation process is complete for each package, the followingmessage is displayed:Installation of package successful.

4. To start the Access Manager configuration utility, enter the following command:pdconfig



6. Select the component that you want to configure, one at a time.Depending on the component that you selected, you are prompted forconfiguration options. For assistance with these configuration options, see page“Native installation configuration options” on page 119.


8. Optional: To install and configure the Java Runtime Environment, skip thesesteps and follow instructions in “Installing and the configuring Access ManagerJava Runtime Environment”.



To install and configure the Access Manager Java Runtime Environment, followthese steps:1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Base for Solaris, Version 3.9 CD.3. To install the prerequisite JRE package for Solaris, enter the following

command:cp -r /cdrom/cdrom0/solaris/j2re1_3_1_01 destination

where /cdrom/cdrom0/solaris is the directory.


4. Set the environmental variable path by entering the following:set env PATH=$PATH: jre_path

5. To install the Access Manager Java Runtime Environment, enter the followingcommand:pkgadd -d /cdrom/cdrom0/solaris -a /cdrom/cdrom0/solaris/pddefault PDJrte

where -d /cdrom/cdrom0/solaris specifies the location of the package and -a/cdrom/cdrom0/solaris/pddefault specifies the location of the installationadministration script, either on the CD.

The Choose Setup Language dialog is displayed.6. Select the language that you want to use for the installation and click OK.7. The Welcome screen is displayed. Click Next to continue.


8. Read the license agreement and click Yes if you agree to the terms. TheChoose Destination Location dialog is displayed if you have not installed asupported runtime environment.








1. Review “Web portal manager installation considerations”.2. Install the IBM Global Sign-on Toolkit (GSKit). See “Installing the IBM Global




WebSphere Application Server FixPack 2” on page 118.6. Install the Access Manager runtime component. See “Installing and configuring

IBM Tivoli Access Manager” on page 114.7. Install and configure the Web portal manager component. See “Installing and

configuring IBM Tivoli Access Manager” on page 114.




Web portal manager installation considerationsBefore you begin using the native installation process, ensure that the followingconditions are met:


v Ensure the policy server is installed and configured before installing Web portalmanager. Web portal manager can be installed on the same system as the policyserver or on a separate system.

v There are two choices for installing WebSphere: typical and custom. Typicalinstallation is recommended. If you choose custom installation, you mustperform one of the following:– Select InstallDB for the Database Type field.– Create a database for WebSphere.

For information on using custom installation, see the following Web site:


both use the IBM HTTP Server as the Web server. It is important to note thatboth WebSEAL and the IBM HTTP Server use a default port of 80. It isrecommended that you change the IBM HTTP Server port number to 8080 sothat your Web server does not interfere with port 80. To change the default portnumber on your system, edit the /opt/IBMHTTPD/conf/httpd.conf file, andchange the port number as shown:# Port: The port the standalone listens to.Port 8080


v The configuration process automatically configures the IBM WebSphereApplication Server for Secure Sockets Layer (SSL) support over the port number443. If you encounter any problems after configuration, it is recommended thatyou stop and restart the IBM HTTP Server. To restart the server, enter thefollowing:opt/IBMHTTPD/bin/apachectl restart


/var/PolicyDirector/keytab/pdwpm.kdbSpecifies the key database file. The path of the file is specified in thehttpd.conf file.

/var/PolicyDirector/keytab/pdwpm.sthSpecifies the file where the key database password is stored.





Installing IBM WebSphere Application ServerTo install IBM WebSphere Application Server, follow these steps:1. Log in to the system as root.2. Insert the IBM Tivoli Access Manager Web Portal Manager for Solaris, Version 3.9

CD.3. Ensure that the DISPLAY variable is set. For example, enter the following:

echo $DISPLAY

If the result is NULL, you must export the DISPLAY variable and set it to the hostname of your system followed by :0.0. For example, if you are working on asystem named cwyman, enter the following:DISPLAY=cwyman:0.0

export DISPLAY

4. From a command prompt, change to the /solaris/WebSphere directory on thedrive where the CD is located and enter the following:./install.sh

5. To use the graphical user interface to install WebSphere, skip to step 6. To use aresponse file (silent installation), run the install.sh script as follows and thenskip to “Installing IBM WebSphere Application Server FixPack 2”../install.sh -silent -responseFile ./install.script \-prereqfile ./prereq.properties

Note: Ensure that you view the screen in case you are prompted forinstructions or an error occurs.

6. To install using the GUI, run the install.sh script, located in the currentdirectory as follows:./install.sh

The WebSphere Application Server, Advanced Single Server Edition v4.0window is displayed. Click Next to continue.

7. Select Typical installation (the default choice) and click Next.8. Default paths are displayed for the WebSphere Application Server destination

directory and IBM HTTP Server. If the system already has the IBM HTTPServer installed on it, this choice does not appear. Accept these defaults byselecting Next.

Note: Make a note of these paths as they are needed during the installation ofthe WebSphere Application Server FixPack 2. The default path for theapplication server is /opt/WebSphere/AppServer. The default path for theIBM HTTP Server is /opt/IBMHTTPD if it installed as part of theWebSphere installation. If the HTTP Server is installed as part of the Webportal manager easy installation, or as part of the Access Managerinstallation, the default path is /opt/IBMHTTPD.

A dialog is displayed indicating your installation selections. Select Install tobegin the installation process.

9. To install the FixPack, see“Installing IBM WebSphere Application ServerFixPack 2”.

Installing IBM WebSphere Application Server FixPack 2To install IBM WebSphere Application Server FixPack 2, follow these steps. Notethat for systems running in Simplified Chinese, German, and Italian, you mustinstall FixPack 3 instead of FixPack 2 as instructed. To download FixPack 3 for


WebSphere Application Server, Advanced Single Server Edition, Version 4.0, see theSupport downloads link at the following Web site:


installed on the same system).2. Insert the IBM Tivoli Access Manager Web Portal Manager for Solaris, Version 3.9

CD.3. From a command prompt, change to the solaris/WebSphere_PTF2 directory.4. Copy the contents of the WebSphere_PTF2 directory into a temporary directory

on your system.5. Open a command prompt and change directories to this temporary directory.6. Run install.sh.7. When prompted, enter the directory where the IBM WebSphere Application

Server is installed and press Enter. The default directory is/opt/WebSphere/AppServer.

8. When prompted if you want to upgrade the IBM HTTP Server, select Yes.9. When prompted, enter the directory where IBM HTTP Server is installed and

press Enter. The default directory is /opt/IBMHTTPD.The upgrade begins. A prompt displays the message Upgrading IBM JDK. Thisupgrade installs the IBM Developer Kit for Solaris in the WebSphere directory.There is not a conflict if you already have the toolkit installed elsewhere onyour system.When the upgrade is complete, a prompt displays the message Installationcompleted with no errors. Please view the activity log for details.Press any key to continue.




Note that the configuration information for the policy server is used forconfiguring other Access Manager components. You are not prompted forconfiguration options for GSKit, the IBM SecureWay Directory client, the ADK,Web portal manager, and Access Manager JRE components.

Access Manager runtimeDuring the configuration of the Access Manager runtime environment on a Solarissystem, you are prompted for the following information:v LDAP server hostname—Specifies the fully qualified host name of the LDAP





v Hostname of the Policy Server—Specifies the fully qualified host name of thepolicy server. For example:pdmgr.tivoli.com

v SSL listening port used by Policy Server— Specifies the port number on whichthe policy server listens for SSL requests. The default port number is 7135.

Policy serverDuring the configuration of the policy server on a Solaris system, you areprompted for the following information:v LDAP administrative DN—Specifies the distinguished name of the LDAP

administrator. The default name is cn=root.v LDAP administrative password—Specifies the password associated with the





– SSL client certificate label (if required)—Specifies the label in the clientGSKit key database file of the client certificate to be sent to the server. Thislabel is required if the server is configured to require client authenticationduring SSL establishment. If you use the ezinstall_ldap_server script andthe default key file (pd_ldapkey.kdb), then the label for configuring the LDAPserver should be left blank. Typically, the LDAP server requires onlyserver-side certificates that were specified during creation of the client .kbdfile. In addition, if the SSL client key file label is not required, leave this fieldblank when configuring the policy server.










If this option is set to no, you must copy the pdcacert.b64 file to each AccessManager runtime system.

Authorization serverDuring the configuration of the authorization server on a Solaris system, you areprompted for the following information:v LDAP administrative DN—Specifies the distinguished name of the LDAP

administrator. The default name is cn=root.v LDAP administrative password—Specifies the password associated with the






Note: If the SSL client key file label is not required, leave this field blankwhen configuring the policy server.

– LDAP SSL client key file password—Specifies the password of the clientGSKit key database file. The pd_ldapkey.kdb file shipped with easyinstallation has a default password of gsk4ikm. These defaults are usable ifyou install and configure the IBM SecureWay Directory server using the


ezinstall_ldap_server script. If you decide to change this password usingthe gsk5ikm utility, you must recall this default password.


v Access Manager Administrator password—Specifies the password associatedwith the sec_master primary administrator ID.











want to unconfigure. You must unconfigure components in the reverse orderthat you configured them. For example, unconfigure components in thefollowing order:

PDJrte Indicates the Java Runtime Environment.





PDMgr Indicates the policy server.5. Repeat this procedure for each package that you want to unconfigure.

If you are unconfiguring a server, a prompt is displayed requesting thedistinguished name and password of the LDAP administrative user.




Removing IBM Tivoli Access ManagerTo remove components from a Solaris system, follow these steps:1. Ensure that the components are unconfigured. To unconfigure components,

follow the instructions in “Unconfiguring IBM Tivoli Access Manager” onpage 122.

2. To remove one or more packages, enter the following:pkgrm package





PDRTE Indicates the Access Manager runtime.


IBMldapc Indicates the IBM SecureWay Directory client.

gsk5bas Indicates GSKit.3. When prompted to confirm the removal of these components, enter y.




Chapter 7. Installing IBM Tivoli Access Manager on Windows

This chapter provides information about installing and configuring IBM TivoliAccess Manager (Access Manager) components on Windows systems. Instructionsare provided for both easy and native installation methods. Before you begin,make sure that you review the installation process on page 11 and are familiarwith configuration decisions that you need to make during installation.




Installation is performed through the use of batch files for Windows systems.These batch files make it easy for you to install Access Manager by automaticallyinstalling software prerequisites at the same time. They also let you know whichcomponents are currently installed and prompt you for configuration information.After you supply the necessary configuration options, the batch file installs andconfigures the components without further intervention. And if you ever need toinstall these components again, you can use the associated response file that isgenerated when you run an easy installation script. The response file automaticallystores the configuration information that you entered. For more information aboutresponse files, see “Using response files” on page 131.


listed in “Software requirements” on page 5.v You must install and configure only one policy server for each secure domain.v If you want to view the status and messages in a language other than English


v When using the ezinstall_pdmgr.bat file to install the policy server, it is notnecessary to also run the ezinstall_pdrte.bat file. The runtime component isinstalled with the policy server component. Run the ezinstall_pdrte.bat fileonly if you want to set up a separate Access Manager runtime system.

v The Access Manager runtime cannot be configured until the policy server isinstalled. If the runtime environment is already configured, you mustunconfigure it, install the policy server, and then configure both packages.


v If you plan to install IBM SecureWay Directory server, review the followingconsiderations:– The IBM HTTP Web server is installed with the ezinstall_ldap_server.bat

file, which installs the IBM SecureWay Directory server. If you plan to installa Web server other than IBM HTTP, do not use easy installation to install theIBM SecureWay Directory server. Follow the native installation instructions inthe IBM SecureWay Directory Installation and Configuration Guide.

– It is recommended that you run the ezinstall_ldap_server.bat script onWindows NT file systems (NTFS).

– The ezinstall_ldap_server.bat file adds required suffixes and necessarydirectory entries to the directory information tree (DIT) for the IBMSecureWay Directory server. However, depending on your organizationalrequirements, you might decide to create additional suffixes for user andgroup definitions. For more information, see “LDAP server configurationoverview” on page 33.

v If you plan to install Web portal manager, review the following considerations:– Ensure the policy server is installed and configured before installing Web

portal manager. Web portal manager can be installed on the same system asthe policy server or on a separate system.

– IBM HTTP Server is installed with the IBM WebSphere Application Server. Ifyou plan to install a Web server other than IBM HTTP, do not use easyinstallation to install Web portal manager. Follow the native installationinstructions in the “Installing and configuring Web portal manager” on page139.

Easy installation scriptsThe following easy installation scripts (except ezinstall_pdwpm.bat) are located inthe root directory on the IBM Tivoli Access Manager Base for Windows, Version 3.9.The Web portal manager batch file, ezinstall_pdwpm.bat, is located on the IBMTivoli Access Manager Web Portal Manager for Windows, Version 3.9 CD.

Use these files to set up Access Manager systems or to add components to existingones. For example, you might run ezinstall_ldap_server.bat to set up an LDAPserver system and then run ezinstall_pdmgr.bat on a different system to install aseparate policy server. Or, you might run both batch files to install and configurethese components on the same system.

Easy installation scripts detect when required products are installed and do notattempt to reinstall them. For example, if you run ezinstall_pdmgr.bat on asystem that is already set up using ezinstall_ldap_server.bat, it does notreinstall GSKit, or the IBM SecureWay Directory client.

Keep in mind that you have to reboot your system throughout the easy installationprocess on Windows systems. During the installation process you might alsoreceive notification that some services did not start. No action is necessary.Continue with the installation process.

Note: For descriptions of information that you are prompted for duringconfiguration, see “Easy installation configuration options” on page 127. Fora step-by-step example with illustrations, see Appendix C, “Easy installationscenarios” on page 211.

ezinstall_ldap_server.bat (IBM SecureWay Directory server)Sets up a system with the following software packages:


v IBM DB2 Universal Database Editionv IBM Global Security Toolkit (GSKit)v IBM HTTP Serverv IBM SecureWay Directory clientv IBM SecureWay Directory server

ezinstall_pdrte.bat (runtime)Sets up a system with the following software packages:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory clientv Access Manager runtime

ezinstall_pdmgr.bat (policy server)Sets up a system with the following software packages:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory clientv Access Manager runtimev Policy server

ezinstall_pdacld.bat (authorization server)Sets up a system with the following software packages:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory clientv Access Manager runtimev Authorization server

ezinstall_pdauthadk.bat (ADK)Sets up a system with the following software packages:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory clientv Access Manager runtimev ADK

ezinstall_pdwpm.bat (Web portal manager)Sets up a system with the following software packages:v GSKitv IBM SecureWay Directory clientv Access Manager runtimev IBM WebSphere Application Server with PTFv IBM HTTP Serverv Web portal manager

Easy installation configuration optionsThis section lists configuration information that is required during the easyinstallation process. It is recommended that you identify these values before youare prompted during installation. If you are planning to enable Secure SocketsLayer (SSL), configuration options also are provided.

Note that the configuration information for the policy server is used forconfiguring other Access Manager components. Configuration is not required forGSKit, the IBM SecureWay Directory client, the ADK, and the Web portal managercomponents. You are only prompted to change the default installation directory.

Chapter 7. Installing IBM Tivoli Access Manager on Windows 127

IBM SecureWay Directory serverDuring the configuration of the IBM SecureWay Directory server on a Windowssystem, you are prompted for the following information:v IBM DB2 configuration options are as follows:

– DB2 Administrator ID —Specifies the DB2 administrator user that is createdduring configuration. The default user ID is db2admin.

– DB2 Administrator Password —Specifies the DB2 administrator ID password.Supply a password for the DB2 administrator.

– Installation Path —Specifies where to install the DB2 product and store thedatabase.

v IBM HTTP Server configuration options are as follows:– Administration ID—Specifies the administrator ID with which you logged on

to your system. This ID must already exist and have administrator authority.– Administration Password—Specifies the password associated with the

Administration ID.– HTTP Port—Specifies the port number used by IBM HTTP Server. It is

important to note that both WebSEAL and IBM HTTP Server use a defaultport of 80. It is recommended that you change the IBM HTTP Server portnumber to 8080 so that your Web server does not interfere with port 80.



v LDAP Server Hostname—Specifies the fully qualified host name of the LDAPserver. For example:ldapserver.tivoli.com

v Suffix—Specifies the distinguished name of where in the LDAP server directoryinformation tree (DIT) that the Global Sign-On (GSO) database is located. Forexample:o=tivoli,c=us



v Enable SSL between Access Manager and LDAP—Specifies whether SSLshould be enabled (yes or no). If yes is specified, the following information isrequested.– LDAP SSL Key File—Specifies the fully qualified path name where the client

GSKit key database file, pd_ldapkey.kdb , is located on the policy server. Thiskey file gets copied from the media\common directory to the followingdirectory:c:\keytabs\pd_ldapkey.kdb

To enable SSL communication, you must manually copy this file from itslocation on the LDAP server to a directory on the policy server.

– SSL Client Certificate Label (if required)—Specifies the label in the clientGSKit key database file of the client certificate to be sent to the server. Thislabel is required if the server is configured to require client authenticationduring SSL establishment. If you use the ezinstall_ldap_server script andthe default key file (pd_ldapkey.kdb), then the label for configuring the LDAP


server is PDLDAP. Typically, the LDAP server requires only server-sidecertificates that were specified during creation of the client .kbd file.


Access Manager runtimeDuring the configuration of the Access Manager runtime environment on aWindows system, you are prompted for the following information:v Configure Using This Registry Type—Specifies the registry type.

Note: The only valid value is LDAP.v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP



v Suffix—Specifies the distinguished name of where in the LDAP server directoryinformation tree (DIT) that the Global Sign-On (GSO) database is located. Forexample:o=tivoli,c=us


v Enable SSL between Access Manager and LDAP—Specifies whether SSLshould be enabled (yes or no). If yes is specified, the following information isrequested.– LDAP SSL Key File—Specifies the fully qualified path name where the client

GSKit key database file is located on the client system.If you plan to enable SSL communication between your LDAP server andIBM SecureWay Directory clients that support Access Manager software, youmust manually copy the C:\keytabs\pd_ldapkey.kdb file from its location onthe LDAP server to a directory on your client systems.

– LDAP SSL Key File DN (if required)—Specifies the label in the client GSKitkey database file of the client certificate to be sent to the server. This label isrequired if the server is configured to require client authentication during SSLestablishment. If you use the ezinstall_ldap_server script and the defaultkey file (pd_ldapkey.kdb), then the label should be left blank. Typically, theLDAP server requires only server-side certificates that were specified duringcreation of the client .kbd file. In addition, if the SSL client key file label is notrequired, leave this field blank when configuring the runtime.

– LDAP SSL Key File Password—Specifies the password of the client GSKitkey database file. The pd_ldapkey.kdb file shipped with easy installation has adefault password of gsk4ikm. These defaults are usable if you install andconfigure the IBM SecureWay Directory server using theezinstall_ldap_server script. If you decide to change this password usingthe gsk5ikm utility, you must recall this default password.



v Installation Directory—Specifies the directory where the Access Managerruntime environment is installed.

If the Access Manager policy server is not installed on the same system as theAccess Manager runtime environment, then you are also prompted for thefollowing information:v Access Manager Policy Server Hostname—Specifies the fully qualified host

name of the policy server. For example:pdmgr.tivoli.com

v SSL Server Port for Access Manager Policy Server— Specifies the port numberon which the policy server listens for SSL requests. The default port number is7135.

v Policy Server CA Certificate Filename—If you specified to enable automaticdownloading of the CA certificate file (pdcacert.b64) during the configuration ofthe Access Manager policy server, leave this option blank. It is not needed whenconfiguring the Access Manager runtime environment.If you do not select to enable automatic downloading of the CA certificate file,you must manually copy the /var/PolicyDirector/keytab/pdcacert.b64 filefrom the policy server system locally to a directory on the runtime system.

Policy serverDuring the configuration of the policy server on a Windows system, you areprompted for the following information:v LDAP Administrator ID (DN)—Specifies the distinguished name of the LDAP

administrator. The default name is cn=root.v LDAP Administrator Password—Specifies the password associated with the

LDAP administrator ID.v Security Master Password—Specifies the password associated with the

sec_master primary administrator ID.v SSL Server Port—Specifies the port number on which the policy server listens

for SSL requests. The default port number is 7135.v Policy Server SSL Certificate Lifetime— Specifies the number of days that the

SSL certificate file is valid. The default number of days is 365.v Enable Download of Certificates—Specify yes to enable automatic downloading

of the SSL certificate authority file during configuration of the policy server. Ifyou specify no, the SSL certificate authority file is placed in the followingdirectory:install_dir\keytab\pdcacert.b64


Authorization serverDuring the configuration of the authorization server on a Windows system, youare prompted for the following information:v LDAP Administrator ID (DN)—Specifies the distinguished name of the LDAP



sec_master primary administrator ID.



This section includes the following sections:v “Creating a response file” on page 61v “Installing components using a response file” on page 61v “Response file example” on page 62v “Response file stanza-keyword options” on page 133

Note: Considerations for response files are the same as those for easy installation.For more information, see “Easy installation considerations” on page 125.


Easy installation generates a response file named ezinstall.rsp. This response fileresides in the temporary directory that is the value specified by the %TEMP%variable. For example, if you run the ezinstall_pdrte file, the response file that isgenerated is named %TEMP%\ezinstall.rsp.

Response files enable you to set up the following Windows systems:v IBM SecureWay Directory serverv Access Manager runtimev Policy serverv Authorization serverv ADKv Web portal manager


accurate. For descriptions of the stanzas in the response file, see “Response filestanza-keyword options” on page 133. Note that you can supply actualpasswords for the values at this time, or wait until you are prompted forpasswords when ezinstall is run with the response file.

2. Run the easy installation script and specify the response file. For example, enterthe following:ezinstall_pdrte.bat c:\temp\ezinstall.rsp

where c:\temp\ezinstall.rsp is the fully qualified name of the response file.

Response file exampleA response file contains stanzas of attribute=value pairs. A stanza starts with aline containing the stanza name in brackets, for example, [LDAPS], and ends either


when another line begins with another stanza name in brackets or when the end ofthe file is reached. Each stanza contains zero or more attribute=value pairs. Astanza name cannot be repeated more than once in a response file. Comments canbe added to a response file by using the character # before the comment.

The following is an example of a Windows response file generated from easyinstallation scripts. Note that easy installation pauses during configuration to allowyou to specify any missing values.


[PDRTE]registry-type=ldapldap-server=ldapserv.tivoli.comldap-port=389ldap-ssl-port=636pdmgr-host=pdmgr.tivoli.comcacert=enable-ssl=Yssl-client-keyfile=c:\keytabs\pd_ldapkey.kdbssl-client-keyfile-dn=suffix=o=tivoli,c=uspdmgr_ssl_port=7135pdc_dir=C:\Program Files\Tivoli\Policy Directorssl-client-keyfile-pwd=gsk4ikm

[PDMGR]ldap-admin-id=cn=rootldap-admin-pwd=secretssl-port=7135cert-life=365enable-cert-download=Ysec-master-pwd=secret

[DB2]admin-pwd=db2admininstall_dir=C:\SQLDIR

[HTTPD]admin-id=administratoradmin-pwd=secretport=80install_dir=C:\Program Files\IBM HTTP Server

[LDAPS]admin-id=cn=rootadmin-pwd=secrethostname=ldapserv.tivoli.comserver-port=389suffix=o=tivoli,c=usssl-client-keyfile=c:\keytabs\pd_ldapkey.kdbssl-client-keyfile-pwd=gsk4ikmlabel=PDLDAP

[PDACLD]admin-id=cn=rootadmin-pwd=secretsec-master-pwd=secret

[LDAP]install_dir=C:\Program Files\IBM\LDAP


Response file stanza-keyword optionsThe following table shows the various stanza-keyword options available for use ina response file.

Stanza Name Win32 Keyword Description

[DB2] admin-pwd Specifies the administrator’s password. If you login to a Windows system as Administrator, use thedefault password of db2admin.

[DB2] admin-uid Specifies the administrator’s user name. If you login to a Windows system as Administrator, use thedefault password of db2admin.

[DB2] install_dir Specifies the installation directory (WIN32 only).Specify the drive and directory. For example:C:\SQLDIR

[HTTPD] admin-id Specifies the administrator’s user name. The defaultis Administrator.

[HTTPD] admin-pwd Specifies the administrator’s password.

[HTTPD] port Specifies the port that HTTPD uses.

[HTTPD] install_dir Specifies the installation directory. Specify the driveand directory. For example: C:\Program Files\IBMHTTP Server

[LDAP] install_dir Specifies the installation directory (WIN32 only).Specify the drive and directory. For example:C:\Program Files\IBM\LDAP. The LDAP client andserver software reside in this directory.

[LDAPS] admin-id Specifies the LDAP administrator ID orDistinguished Name (DN). The default is cn=root.

[LDAPS] admin-pwd Specifies the LDAP administrator password.

[LDAPS] hostname Specifies the LDAP server host name. The defaultis the host name of the system being configured.

[LDAPS] server-port Specifies the LDAP server non-SSL port number.The default port number is 389.

[LDAPS] suffix Specifies the LDAP distinguished name for theGlobal Sign On (GSO) database. For example,o=tivoli,c=us.

[LDAPS] ssl-client-keyfile Specifies the path to the LDAP SSL key file. Thedefault is /common/pd_ldapkey.kdb, which isshipped on the CD. If this file is used, thepassword of gsk4ikm and the server-side label ofPDLDAP are required.

[LDAPS] ssl-client-keyfile-pwd

Specifies the password associated with the key file.If using the default ofmedia/common/pd_ldapkey.kdb, the password isgsk4ikm.

[LDAPS] label Specifies the label associated with the SSL key file.If using the default ofmedia/common/pd_ldapkey.kdb, the label isPDLDAP.

[GSKIT] install_dir Specifies the installation directory (WIN32 only).Specify the drive and path. For example:C:\Program Files\IBM\GSK



[PDMGR] ldap-admin-id Specifies the LDAP administrator ID. The default iscn=root. This ID is created during theconfiguration of the LDAP server.

[PDMGR] ldap-admin-pwd Specifies the LDAP administrator password.

[PDMGR] ssl-port Specifies the LDAP server non-SSL port. Thedefault port number is 389.

[PDMGR] cert-life Specifies the lifetime of the certificate file(pdcacert.b64). The default is 365 days.

[PDMGR] enable-cert-download

Specifies to enable Access Manager runtimeenvironments on other systems to automaticallydownload the certificate file (pdcacert.b64). Validvalues are Y (enable) or N (disable).


[PDRTE] registry-type Specifies the registry type. The only valid value isldap.

[PDRTE] ldap-server Specifies the host name of the LDAP server.

[PDRTE] ldap-port Specifies the LDAP server non-SSL port. Thedefault port number is 389.

[PDRTE] ldap-ssl-port Specifies the LDAP server SSL port. The defaultport number is 636.

[PDRTE] pdmgr_ssl_port Specifies the policy server SSL port. The defaultport number is 7135.

[PDRTE] pdmgr-host Specifies the host name of the policy server.

[PDRTE] cacert Specifies the path to the policy server certificate file(pdcacert.b64). This is required if the policy serverdoes not allow automatic downloading of the fileby the Access Manager runtime environmentclients.

[PDRTE] enable-ssl Specifies to enable SSL communication with theLDAP server. Valid values are Y (enable) or N(disable).

[PDRTE] ssl-client-keyfile Specifies the path to the SSL key file from theLDAP server (required if SSL is enabled). This filemust be manually obtained from the LDAP serversystem.

[PDRTE] ssl-client-keyfile-pwd

Specifies the password associated with the LDAPSSL client key file.

[PDRTE] ssl-client-keyfile-dn

Specifies the label associated with the LDAP SSLclient key file of client-side-type key files. Thedefault is blank (null). This value is used only ifSSL is enabled.

[PDRTE] suffix Specifies the LDAP distinguished name for theGSO database.

[PDRTE] pdc_dir Specifies the installation directory (WIN32 only).Specify the drive and path. For example:C:\Program Files\Tivoli\PolicyDirector AccessManager components reside in this directory.

[PDACLD] admin-id Specifies the LDAP administrator ID. The default iscn=root. This ID is created during theconfiguration of the LDAP server.



[PDACLD] admin-pwd Specifies the LDAP administrator password.

[PDACLD] sec-master-pwd Specifies the security master password. Thispassword is created during the configuration of thepolicy server.

[WEB] install_dir Specifies the installation directory for the IBMWebSphere Application Server, which is aprerequisite for the Web portal manager. Specifythe drive and directory. For example:C:\WebSphere\AppServer

Using native installationThis section includes information about how to install and configure AccessManager components using native operating system utilities. Unlike the automatedscripts used in easy installation, you must manually install each component andany necessary patches.

This section includes the following main topics:v “Native installation considerations”v “Installing the IBM Global Security Toolkit” on page 136v “Installing the IBM SecureWay Directory client” on page 136v “Installing and configuring IBM Tivoli Access Manager” on page 137v “Installing and configuring the Access Manager Java Runtime Environment” on


Native installation considerationsBefore you begin using the native installation process, ensure that the followingconditions are met:v Ensure that you have installed any software prerequisites and met requirements

listed in“Software requirements” on page 5.v You must install and configure only one policy server for each secure domain.v If you are installing the policy server, you must install the runtime component

first. However, you must not configure the runtime until the policy server isinstalled.


v If you are installing the runtime on a different host system than the policy serverand download certificate is not enabled for this policy server, you must obtain theSSL certificate file from the policy server system. To do this, use a file transferprogram, such as ftp, to place a copy of the file in a location of your choice. Onthe policy server, the certificate file is located in the following directory:install_dir/keytab/pdcacert.b64

Note that you should copy this file after installing the runtime but beforeconfiguring this component.


Installing the IBM Global Security ToolkitTo install GSKit on a Windows system, follow these steps:1. Log in to the system as a user with administrator privileges.2. Insert the IBM Tivoli Access Manager Base for Windows, Version 3.9 CD.3. From a command prompt, change to the windows\gskit directory on the drive

where the CD is located and enter the following:setup.exe PolicyDirector

The Welcome dialog is displayed.4. Click Next. The Choose Destination Location dialog is displayed.5. Accept the default destination directory or click Browse to select a path to

another directory on the local system. If the directory does not exist, you mustconfirm that you want the directory created or specify a directory that exists.

6. Click Next to install GSKit. The Setup Complete dialog is displayed.7. Click Finish to exit the installation program.8. Restart your system.



Installing the IBM SecureWay Directory clientTo install the IBM SecureWay Directory client on a Windows system, follow thesesteps:

Note: If you installed Active Directory as your user registry, the IBM SecureWayDirectory client is not required.

1. Log in to the system as a user with administrator privileges.2. Ensure that you have installed GSKit. For instructions, see “Installing the IBM

Global Security Toolkit” on page 136.3. Insert the IBM Tivoli Access Manager Base for Windows, Version 3.9 CD.4. Run the setup.exe file in the following directory:

windows\Directory\ldap32_us

The Choose Setup Language dialog is displayed.5. Select the language that you want to use for the installation and click OK. The

Software License Agreement dialog is displayed.6. Read the license agreement and click Accept if you agree to the terms. The

Welcome dialog is displayed.7. Ensure that you have closed any running Windows programs and click Next

to continue. A dialog similar to the following is displayed. This informs you of


packages that are already installed.

8. Click Next to keep product versions that are currently installed. The SetupComponents dialog is displayed.

9. Click Express to install the IBM SecureWay Directory client. The clientsoftware development kit (SDK) and directory management tool (DMT) areautomatically installed with the IBM SecureWay Directory client package.

10. From the Express Installation dialog, select the IBM SecureWay Directoryclient as shown:

You can preview the disk space required and change the destination directory.To continue, click Next. The Select Program folder dialog is displayed.

11. Select a program folder and click Next.12. Review your current settings and then click Next to start copying files.13. After the files are installed, you are asked whether you want to view the

README file. Click either Yes or No. After you close the README window,or if you selected No, the Setup Complete dialog is displayed.

14. Select whether you want to restart your system now or later and click Finish.


Installing and configuring IBM Tivoli Access ManagerYou must configure each Access Manager package that has been installed exceptfor the ADK where configuration is not required. Also, you must configure the


Access Manager runtime before configuring any other package. For descriptions ofconfiguration options you are prompted for, see “Native installation configurationoptions” on page 144.

To install Access Manager components, follow these steps:1. Log in to the Windows domain as a user with Windows administrator

privileges.2. To install Access Manager components, insert the IBM Tivoli Access Manager

Base for Windows, Version 3.9 CD and run the setup.exe file in the followingdirectory:windows\PolicyDirector\Disk Images\Disk1

The Choose Language Setup dialog is displayed.3. Select the language that you want to use for the installation and click OK. The

Welcome dialog is displayed.4. Click Next. The License Agreement dialog is displayed.5. Read the license agreement and click Yes if you agree to the terms. The Select

Packages dialog is displayed.6. Select the packages that you want to install on your system and click Next. If

you selected to install the runtime environment, the Access Manager RuntimeSetup dialog is displayed. Choose a destination folder where you want theruntime setup files to be installed and click Next.When installation is completed, the Access Manager Installation Completedialog is displayed.

7. Restart your system for changes to take effect.8. After restarting your system, select Start → Programs → Access Manager for

e-business → Configuration. The Access Manager Configuration dialog isdisplayed.

9. Select a component to configure and click Configure. You must configure eachcomponent separately and in the order listed.

10. Depending on the component that you selected, you are prompted forconfiguration options. For assistance with these configuration options, see“Native installation configuration options” on page 144. After configuration iscomplete, the Access Manager Configuration window is displayed again.

11. Review your selections and click Finish. The Access Manager Configurationwindow is displayed. Select another component in the list to configure or clickClose to exit the tool.

12. Optional: To install and configure the Access Manager Java RuntimeEnvironment, see “Installing and configuring the Access Manager JavaRuntime Environment”.


Installing and configuring the Access Manager Java RuntimeEnvironment

To install and configure the Access Manager Java Runtime Environment, followthese steps:1. Log in to the Windows domain as a user with Windows administrator

privileges.2. Insert the IBM Tivoli Access Manager Base for Windows, Version 3.9 CD.


3. To install the prerequisite JRE package for Windows, enter the followingcommand:cd_drive\windows\JRE\install.bat


4. Set the environmental variable path by entering the following:set PATH=%PATH%; install_dir

5. After you install the prerequisite JRE, delete the IBMJCEfw.jar file in thefollowing directory:jvm_path\jre\lib\ext

6. To install the Access Manager JRE component, run the setup.exe file in thefollowing directory:windows\PolicyDirector\Disk Images\Disk1\PDJRTE\Disk Images\Disk1






13. To configure the Java Runtime Environment for use within the current JRE,change to the install_dir\sbin directory and then enter the followingcommand:pdjrtecfg -action config




1. Review “Web portal manager installation considerations” on page 140.2. Install the IBM Global Sign-on Toolkit (GSKit). See “Installing the IBM Global




WebSphere Application Server FixPack 2” on page 143.


6. Install the Access Manager runtime component. See “Installing and configuringIBM Tivoli Access Manager” on page 137.

7. Install and configure the Access Manager Web portal manager component. See“Installing and configuring IBM Tivoli Access Manager” on page 137.




Web portal manager installation considerationsBefore you begin using the native installation process, ensure that the followingconditions are met:v Ensure the policy server is installed and configured before installing Web portal

manager. Web portal manager can be installed on the same system as the policyserver or on a separate system.

v If you install WebSphere after installing the Access Manager runtime, ensure thatGSKit, Version 5.0.4.67 is installed for Access Manager.

v There are two choices for installing WebSphere: typical and custom. Typicalinstallation is recommended. If you choose custom installation, you mustperform one of the following:– Select InstallDB for the Database Type field.– Create a database for WebSphere.

For information on using custom installation, see the following Web site:


both use the IBM HTTP Server as the Web server. It is important to note thatboth WebSEAL and the IBM HTTP Server use a default port of 80. It isrecommended that you change the IBM HTTP Server port number to 8080 sothat your Web server does not interfere with port 80. To change the default portnumber on your system, edit the http_installation_dir/conf/httpd.conf fileand change the port number as shown:# Port: The port the standalone listens to.Port 8080


v The configuration process automatically configures the IBM WebSphereApplication Server for Secure Sockets Layer (SSL) support over the port number443. If you encounter any problems after configuration, it is recommended thatyou stop and restart the IBM HTTP Server. To restart the IBM HTTP Server, goto the services panel and click Stop and then Start.



C:\Program Files\Tivoli\Policy Director\keytab\pdwpm.kdbSpecifies the key database file. The path of the file is specified in thehttpd.conf file.

C:\Program Files\Tivoli\Policy Director\keytab\pdwpm.sthSpecifies the file where the key database password is stored.




Installing IBM WebSphere Application ServerTo install IBM WebSphere Application Server, follow these steps:1. Log in to the system as a user with administrator privileges.2. Insert the IBM Tivoli Access Manager Web Portal Manager Base for Windows,

Version 3.9 CD.3. From a command prompt, change to the windows\WebSphere directory on the

drive where the CD is located and enter the following:setup.exe

The Choose Setup Language dialog is displayed.4. Select the language that you want to use for the installation and click OK.

5. Ensure that you have closed any running Windows programs and click Nextto continue.

6. Select Typical Installation (default choice), and click Next.


7. In the Security Options window, enter a user name and password, and thenselect Next. This is a user name and password for WebSphere, and must be auser ID and password on the local system.

8. The InstallShield program presents a default path for the WebSphereApplication Server destination directory and IBM HTTP Server. If the systemalready has the IBM HTTP Server installed on it, this choice does not appear.Accept these defaults by selecting Next.

Note: Make a note of these paths as they are needed during the installation ofthe WebSphere Application Server FixPack 2. The default path for theapplication server is C:\WebSphere\AppServer. The default path for theIBM HTTP Server is C:\IBM HTTP Server if it installed as part of theWebSphere installation. If it is installed as part of the Web portalmanager easy installation, or as part of the Access Manager installation,then the default path is c:\Program Files\IBM HTTP Server.


9. Select a Windows Program Folder location; the default is IBMWebSphere\Application Server V4.0 AES. Select Next.

The installation process begins. When it completes, a prompt asks if you wantto restart Windows.

10. Select No, do not restart Windows. The system is restarted after the FixPack 2is installed.

11. To install the FixPack, see “Installing IBM WebSphere Application ServerFixPack 2”.

Installing IBM WebSphere Application Server FixPack 2To install IBM WebSphere Application Server FixPack 2, follow these steps. Notethat for systems running in Simplified Chinese, German, and Italian, you mustinstall FixPack 3 instead of FixPack 2 as instructed. To download FixPack 3 forWebSphere Application Server, Advanced Single Server Edition, Version 4.0, see theSupport downloads link at the following Web site:


installed on the same system).2. Insert the IBM Tivoli Access Manager Web Portal Manager for Windows, Version

3.9 CD.3. From a command prompt, change to the windows\WebSphere\ptf402 directory

on the drive where the CD is located.4. Copy the contents of the PTF402 directory into a temporary directory on your

system.5. Open a command prompt and change directories to this temporary directory.6. Run install.bat.7. When prompted, enter the directory where the IBM WebSphere Application

Server is installed and press Enter. The default directory isc:\WebSphere\AppServer.

8. When prompted if you want to upgrade the IBM HTTP Server, select Yes.9. When prompted, enter the directory where IBM HTTP Server is installed and

press Enter. The default directory is either c:\IBM HTTP Server or c:\ProgramFiles\IBM HTTP Server.The upgrade begins. A prompt displays the message Upgrading IBM JDK. Thisupgrade installs the IBM Developer Kit for Windows in the WebSpheredirectory. There is not a conflict if you already have the toolkit installedelsewhere on your system.


When the upgrade is complete, a prompt displays the message Installationcompleted with no errors. Please view the activity log for details.Press any key to continue.





Access Manager runtimeDuring the configuration of the Access Manager runtime component, you areprompted for the following information:v User Registry Selection—Click to select the type of registry you configured for

Access Manager. Choices are as follows:– LDAP Registry (see “LDAP registry”)– Active Directory (see “Active Directory” on page 145)– Domino (see “Lotus Domino” on page 146)

LDAP registry: During the configuration of the Access Manager runtimeenvironment on a Windows system, you are prompted for the followinginformation:v LDAP Server Hostname—Specifies the fully qualified host name of the LDAP






the client GSKit key database file is located on the client system.If you plan to enable SSL communication between your LDAP server andIBM SecureWay Directory clients that support Access Manager software, youmust manually copy the C:\keytabs\pd_ldapkey.kdb file from its location onthe LDAP server to a directory on your client systems.



Note: If the SSL client key file label is not required, then it may be left blankduring the configuration of the runtime.



v Installation Directory—Specifies the directory where the installation scripts arecontained.

If the Access Manager policy server is not installed on the same system as theAccess Manager runtime environment, then you are also prompted for thefollowing information:v Policy Server Hostname—Specifies the fully qualified host name of the policy



v Access Manager CA Certificate Filename—If you specified to enable automaticdownloading of the CA certificate file during the configuration of the AccessManager policy server, leave this option blank. It is not needed whenconfiguring the Access Manager runtime environment.If you did not enable automatic downloading of the CA certificate file, you mustobtain the SSL certificate file from the policy server system. To do this, use a filetransfer program, such as ftp, to place a copy of the file in a location of yourchoice. On the policy server, the following certificate file is provided forevaluation use:/var/PolicyDirector/keytab/pdcacert.b64

You should copy this file after installing the runtime component, but beforeconfiguring it.

Active Directory: If you selected Active Directory as your user registry, you areprompted for the following information:v Multiple domains—Select Yes to use a multiple domain or No to configure a

single domain.– If you selected Yes to use multiple domains, you are prompted for the

following configuration information:- Enable encrypted connection—Specifies whether you want to enable an

SSL connection. This is an optional step during the installation process. Ifyou installed server and client certificates during Active Directory setup,


select Yes. For more information about enabling SSL communication, seeChapter 8, “Enabling Secure Sockets Layer for LDAP registries” onpage 151.

– If you selected No to multiple domains, you are prompted for the following:- Host name—Specifies the Active Directory domain controller server name.

For example:adserver.tivoli.com

- Domain name—Specifies the domain name. For example:dc=adpd,dc=com

- Enable encrypted connection—Specifies whether you want to enable anSSL connection. This is an optional step during the installation process. Ifyou installed server and client certificates during Active Directory setup,select Yes. For more information about enabling SSL communication, seeChapter 8, “Enabling Secure Sockets Layer for LDAP registries” onpage 151.

v Active Directory Other Information—Type the Administrative ID and passwordthat you created in “Creating an Active Directory administrative user” on page31 and then click Next.Notes:– If you specified No for multiple domains, the Active Directory Data

Information panel is displayed. Type the distinguished name where you wantto store Access Manager data. For example,dc=wsm,dc=com

– If you are using Active Directory as your user registry, a activedir.conf fileis created in the following directory:%PD_INSTALL_DIR%\etc

where PD_INSTALL_DIR is the directory where Access Manager is installed.C:\Program Files\Tivoli\Policy Director is the default directory.

Lotus Domino: If you selected Domino as your user registry, you are promptedfor the following information:v Fully qualified domino server name—Specifies the fully qualified name of the

Domino server. For example:Domino/tivoli

v Domino server TCP/IP hostname—Specifies the TCP/IP host name of theDomino server. For example:domino.tivoli.com

v Domino LDAP server port—Specifies the LDAP server port on which theDomino server listens. If you plan to enable SSL, the port number is 636. Fornon-SSL communication, the default port number is 389.

v Enable SSL communication to Domino server—Select Yes or No to enable SSLclient authentication to the Domino server. This is an optional step during theinstallation process. If you installed a client certificate during Domino setup,select Yes. For more information about enabling SSL communication, seeChapter 8, “Enabling Secure Sockets Layer for LDAP registries” on page 151.If you specify Yes, you are prompted for the following information:– Port number—Specifies the SSL port number. The default port number is 636.– Key file with full path—Specifies the client key file that you created when

enabling SSL. When prompted for the Domino server’s key file, provide thename of your LDAP client key database file. For example:


d:\cert\dominoc.kdb

– Certificate label—Specifies the SSL client certificate label. This field isrequired. However, since you do not need to set up client-side certificateauthentication, you can type in any character and it is ignored.

– Key file password—Specifies the password associated with the key file.v Notes client password—Specifies the Notes client password to access the

Domino database.v Access Manager Meta-data Database name—Specifies the database name

associated with Access Manager data. For example:PDdata.nsf

Policy serverDuring the configuration of the policy server on a Windows system, you areprompted for the following information:v LDAP Administrator ID (DN)—Specifies the distinguished name of the LDAP



sec_master primary administrator ID.v SSL Server Port for Policy Server—Specifies the port number on which the

policy server listens for SSL requests. The default port number is 7135.v Policy Server SSL Certificate Lifetime— Specifies the number of days that the

SSL certificate file is valid. The default number of days is 365.v Enable Download of Certificates—Specify yes to enable automatic downloading

of the SSL certificate authority file. Regardless of whether you specify yes or no,the SSL certificate authority file is placed in the following directory:install_dir/keytab/pdcacert.b64

If this option is set to no, you must copy the pdcacert.b64 file to each AccessManager runtime client system.

Authorization serverDuring the configuration of the authorization server on a Windows system, youare prompted for the following information:v LDAP Administrator ID (DN)—Specifies the distinguished name of the LDAP



sec_master primary administrator ID.







unconfiguring the policy server and the Access Manager runtime.v You do not have to unconfigure the ADK before removing it.

Unconfiguring IBM Tivoli Access ManagerTo unconfigure Access Manager components on a Windows system, follow thesesteps.

Note: If you have already unconfigured a Access Manager component, you are notprompted for administrator name and password information during theunconfiguration process. The configuration utility caches this information.

1. Log in as a Windows user with administrator privilege.2. Start the IBM SecureWay Directory and Access Manager Policy Server services.

To do so, select Start → Settings → Control Panel and click Services. Then selectthe IBM SecureWay Directory V3.2 service and click Start. After the server isstarted, repeat this step for the Access Manager Policy Server service.

3. Select Start → Programs → Access Manager for e-business → Configuration.4. From the Access Manager Configuration dialog, click one of the Access

Manager components listed. Components must be unconfigured in thefollowing order:v Access Manager Authorization Server

v Access Manager Policy Server

v Access Manager Runtime

v Access Manager Web Portal Manager

Note: For Active Directory registry users only, ensure that the Administrationconsole application is closed before you unconfigure the Access Managerpolicy server.

5. Click Unconfigure.6. If you selected to unconfigure the authorization server, specify the password

for the Access Manager administrator (sec_master).7. If you selected to unconfigure the policy server, type the LDAP administrator

name (for example, cn=root) and the appropriate password. A warning


message is displayed informing you that by unconfiguring this package,configuration and authorization information for all Access Manager servers inthe secure domain will be removed. Click Yes to remove; click No to exit thistask.

8. To unconfigure another component, repeat steps 4 through 7.9. To unconfigure the Access Manager Java Runtime Environment, use the

pdjrtecfg command. For example, enter the following to unconfigure the JREspecified by the jre_path variable:pdjrtecfg -action unconfig -java_home jre_path


Removing IBM Tivoli Access ManagerTo remove components from a Windows system, follow these steps:1. Log in as a Windows user with administrator privilege.2. Select Start → Settings → Control Panel and then click the Add/Remove

Programs icon.3. Select one of the following components and then click Add/Remove:

v IBM SecureWay Directory V3.2.2

v Access Manager Authorization Server

v Access Manager Application Development Kit

v Access Manager Java Runtime Environment

v Access Manager Policy Server

v Access Manager Runtime

v Access Manager Web Portal Manager

v WebSphere Application Server

The Choose Language Setup dialog is displayed.4. Select the language that you want to use for the removal process and click OK.5. From the Confirm Component Removal message box, click Yes.

The Access Manager component is removed.6. Select another component from the list or click OK to exit the program.7. To remove GSKit from your system, enter the following command:

isuninst -f"c:\program files\ibm\gsk\ibm\gsk5\gsk5bui.isu"

where c:\program files\ibm\gsk\ibm\gsk5 is the fully-qualified path where thegsk5BUI.isu file is located.

Note: You cannot uninstall GSKit using the Add/Remove Programs iconsimilar to the other Access Manager components. For more informationabout the pdjrtecfg command, see “pdjrtecfg” on page 230.



Chapter 8. Enabling Secure Sockets Layer for LDAP registries

It is recommended that you enable Secure Sockets Layer (SSL) communicationbetween your LDAP server and IBM SecureWay Directory clients that support IBMTivoli Access Manager (Access Manager) software.

Note: If you used easy installation to install the IBM SecureWay Directory server,you can skip the instructions in this appendix. The ezinstall_ldap_serverscript steps you through the process of enabling SSL while, at the same time,installing and configuring this LDAP server and its prerequisites.

To enable SSL communication, you must first configure SSL on the LDAP server,and then configure SSL on the IBM SecureWay Directory client. During SSLconfiguration, you are prompted to choose one of the following authenticationtypes:

Server authenticationThe server sends its certificate to the client and the client authenticates theserver.

Server and client authenticationAfter the server has sent its certificate to the client and has beenauthenticated by the client, the server requests the client’s certificate. Inthis case, a certificate needs to be established for the client system as wellas the server.

If you choose to implement server authentication only, you must configure yourLDAP server and IBM SecureWay Directory clients for SSL access. However, if youchoose to implement server and client authentication, you must configure SSL onthe server, configure SSL on the client, and then follow instructions in“Configuring LDAP server and client authentication” on page 163.

This chapter contains the following main sections:v “Configuring the IBM SecureWay Directory server for SSL access”v “Configuring the iPlanet Directory server for SSL access” on page 156v “Configuring the IBM SecureWay Directory client for SSL access” on page 161v “Configuring OS/390 and z/OS SecureWay LDAP servers for SSL access” on

page 158v “Configuring LDAP server and client authentication” on page 163

Configuring the IBM SecureWay Directory server for SSL accessYou can enable the use of SSL to protect communication between the TivoliSecureWay Access Manager servers and the LDAP server. This step needs to bedone only the first time SSL communication is set up between the LDAP serverand the IBM SecureWay Directory client.

If you previously enabled SSL access to the LDAP server during the LDAP serverconfiguration, you must copy a client and server key ring pair to each additionalTivoli SecureWay Access Manager system that uses SSL access.


If SSL access is required by your LDAP server, use GSKit to perform SSL keymanagement. GSKit provides a graphical key management utility named gsk5ikm.

Note: For complete instructions on how to use the gsk5ikm utility to enable SSL,see the IBM SecureWay Installation and Configuration Guide.

To enable SSL access on the IBM SecureWay Directory server, complete theinstructions in the following sections:v “Creating the key database file and the certificate” on page 152v “Obtaining a personal certificate from a certificate authority” on page 153 or

“Creating and extracting a self-signed certificate” on page 153v “Enabling SSL access” on page 154

Creating the key database file and the certificateTo enable SSL support on the LDAP server, the server must have a certificate thatidentifies it and that it can use as a personal certificate. This personal certificate isthe certificate that the server sends to the client to allow the client to authenticatethe server. The certificates and the public and private key pair are stored in a keydatabase file. A user typically acquires a signed certificate from a certificateauthority, such as VeriSign.

Alternatively, a user can use a self-signed certificate. If the user is using aself-signed certificate, the system on which the certificate is generated becomes thecertificate authority.

Use the gsk5ikm utility to create the key database file and the certificate. To createthe key database file and certificate (self-signed or signed), follow these steps:1. Ensure that GSKit, Version 5.0.4.67, and gsk5ikm are installed on both the

LDAP server and any IBM SecureWay Directory clients that will be using SSL.2. Start the gsk5ikm utility, which is located in one of the following directories:

System Path

AIX /usr/lpp/ibm/gsk5/bin/gsk5ikm

HP-UX /opt/ibm/gsk5/bin/gsk5ikm

Linux /usr/local/ibm/gsk5/bin/gsk5ikm

Solaris /opt/IBM/GSK5/bin/gsk5ikm

Windows C:\Program Files\IBM\GSK5\bin\GSK5ikm.exe

3. To create a new key database file, select Key Database File → New.4. Verify that the CMS key database file is the selected key database type.5. Type the information in the File Name and Location fields where you want

the key database file to be located. A key database file’s extension is.kdb.6. Click OK.7. Enter the key database file password, and confirm it. Remember this

password because it is required when the key database file is edited.8. Accept the default expiration time, or change it to your organization’s

requirements.9. If you want the password to be masked and stored into a stash file, select

Stash the password to a file.


A stash file can be used by some applications so that the application does nothave to know the password to use the key database file. The stash file has thesame location and name as the key database file and has an extension of.sth.

10. Click OK. This completes the creation of the key database file. There is set ofdefault signer certificates. These signer certificates are the default certificateauthorities that are recognized.

Obtaining a personal certificate from a certificate authorityIf you plan to use a certificate from a certificate authority instead of a self-signedcertificate, you must request the certificate from the certificate authority and thenreceive it after it has been completed.

If you plan to use a self-signed certificate, skip this section and go to “Creatingand extracting a self-signed certificate”.

To request and receive a certificate, follow these steps:1. Use gsk5ikm to request a certificate from a certificate authority and then

receive the new certificate into your key database file.2. Click the Personal Certificate Requests section of the key database file.3. Click New.4. To produce a request that can be sent to the certificate authority, complete the

information and then click OK.5. To install the certificate to your key database file after the certificate authority

returns it, click the Personal Certificates section and then click Receive.6. After you have the LDAP server’s certificate in the key database file, configure

the LDAP server to enable SSL.

Continue to “Enabling SSL access” on page 154.

Creating and extracting a self-signed certificateIf you obtained a certificate from a known certificate authority, as described in theprevious section “Obtaining a personal certificate from a certificate authority”, skipthis section and go to “Enabling SSL access” on page 154.

To create a new self-signed certificate and store it into the key database file, followthese steps:1. Select Create → New Self-Signed Certificate.2. Type a name in the Key Label field that GSKit can use to identify this new

certificate in the key database. For example, the label can be the system nameof the LDAP server.

3. Accept the defaults for the Version field (X509 V3) and for the Key Size field.4. Either accept the default system name or enter a different distinguished name

in the Common Name field for this certificate.5. Enter a company name in the Organization field.6. Complete any optional fields or leave them blank.7. Either accept the defaults for the Country field and 365 for the Validity

Period field or change them to suit your organization’s requirements.8. Click OK. GSKit generates a new public and private key pair and creates the

certificate.If you have more than one personal certificate in the key database file, GSKitqueries if you want this key to be the default key in the database. You can

Chapter 8. Enabling Secure Sockets Layer for LDAP registries 153

accept one of them as the default. The default certificate is used at runtimewhen a label is not provided to select which certificate to use.This completes the creation of the LDAP server’s personal certificate. It isdisplayed in the Personal Certificates section of the key database file. Use themiddle bar of the key management utility to select between the types ofcertificates kept in the key database file.The certificate also is displayed in the Signer Certificates section of the keydatabase file. When you are in the Signer Certificates section of the keydatabase, verify that the new certificate is there.Next, you must extract your LDAP server’s certificate to a Base64-encodedASCII data file.

9. Use gsk5ikm to extract your LDAP server’s certificate to a Base64-encodedASCII data file. This file is used in “Adding a signer certificate” on page 162.

10. Highlight the self-signed certificate that you just created.11. Click Extract Certificate.12. Click Base64-encoded ASCII data as the data type.13. Type a certificate file name for the newly extracted certificate. The certificate

file’s extension is usually.arm.14. Type the location where you want to store the extracted certificate.15. Click OK.16. Copy this extracted certificate to the IBM SecureWay Directory client system.

You can now configure the LDAP server to enable SSL. Continue to “Enabling SSLaccess”.

Enabling SSL accessTo configure the LDAP server to enable SSL, follow these steps:1. Make sure that the LDAP server is installed and running.2. Use the Web-based LDAP administration tool with the following Web address:

http://servername/ldapwhere servername is the name of the LDAP server system.

3. Log on as the LDAP administrator (for example, cn=root) if you are notalready logged on.

4. Select Security → SSL → Settings.


5. Click either SSL On, which enables SSL, or click SSL Only for the SSL statusthat you want to set. For example:

6. Choose one of the following authentication methods:v Server Authentication

For server authentication, the server sends its certificate to the client andthe client authenticates the server.

v Server and Client Authentication

For server and client authentication, after the server has sent its certificateto the client and has been authenticated by the client, the server requeststhe client’s certificate. In this case, a certificate needs to be established forthe client system also.You must establish the certificate for the client when enabling SSL access forthe client in “Configuring LDAP server and client authentication” onpage 163.

7. Type a port number, or accept the default port number of 636.8. Type the key database path and file name that you specified in “Creating the

key database file and the certificate” on page 152.The key database file’s extension is.kdb.

9. Type the name in the Key Label field that you used to identify it when youstored the LDAP server’s certificate in the key database. For example, thelabel might be the system name of the LDAP server.

10. Enter the key database file password and confirm it. You can leave thepassword field blank if you want the LDAP server to use the stash file.

11. Click Apply.12. Click the restart the server link to restart the LDAP server and allow this

change to take effect.

To test that SSL has been enabled, type the following command from a LDAPserver command line:ldapsearch -h servername -Z -K keyfile -P key_pw -b ""-s base objectclass=*


The command variables are as follows:

Variable Description

servername The DNS host name of the LDAP server.

keyfile The fully qualified path name of the generated keyring.

key_pw The password of the generated key ring.

This command returns the LDAP base information, which includes the suffixes onthe LDAP server.

The LDAP server SSL setup is now complete.

Next, set up the IBM SecureWay Directory client for SSL access. Continue to“Configuring the IBM SecureWay Directory client for SSL access” on page 161.

Configuring the iPlanet Directory server for SSL accessSSL allows the data that is transmitted between the Tivoli SecureWay PolicyDirector services and iPlanet Directory Server to be encrypted to provide dataprivacy and integrity. It is recommended that administrators enable SSL to protectinformation such as user passwords and private data. However, SSL is not requiredfor Tivoli SecureWay Policy Director to operate.

This procedure needs to be done only the first time SSL communication is set upbetween the iPlanet Directory Server and IBM SecureWay Directory clients. Toenable SSL communication, both iPlanet Directory Server and the IBM SecureWayDirectory clients must be configured.

For complete information about enabling SSL access on iPlanet Directory Server,see the iPlanet Directory Server documentation.

Complete the instructions in the following sections:v “Obtaining a server certificate” on page 156v “Installing the server certificate” on page 157v “Enabling SSL access” on page 158

Obtaining a server certificateTo enable SSL support, iPlanet Directory Server requires a certificate that proves itsidentity to client systems. The server sends the certificate to the client to enable theclient to authenticate with the server. This certificate is called a Server-Cert.

Use the iPlanet Console 5.0 and the Certificate Setup Wizard to establish theServer-Cert:1. Start the iPlanet Console 5.0.2. Enter the user ID for the LDAP administrator.3. Enter the password.4. Enter the administration Web address.5. Select the domain to be used by Tivoli SecureWay Policy Director.6. Expand the server name.7. Expand Server Group.


8. Select the entry labeled Directory Server.Configuration information about iPlanet Directory Server is displayed.

9. Click Open. The iPlanet Directory Server is accessed.10. Click the Configuration tab.11. Click the Encryption tab.12. Verify that the Enable SSL for this server check box is not selected.13. Click the Tasks tab and then click Manage Certificates.

Note: The private key for the certificate is stored on an internal securitydevice called a token, which is password protected. The first time thatyou click the Manage Certificates button, you are prompted to createthe password for this token.

14. Enter the Security password twice and then click OK. The ManageCertificates window is displayed.

15. In the Security Device pull-down, ensure that internal (software) is selectedand that the Server Certs tab is selected.

16. Click the Request button at the bottom of the window. The Certificate RequestWizard panel is displayed.

17. Ensure that the Request certificate manually button is selected and clickNext.

18. Enter the requestor information and then click Next. Ensure that you completeall fields. When prompted to continue, click Yes.

19. Ensure that the Active Encryption token field states internal (software).20. Enter the security device password and then click Next.21. To save the certificate request to a file, click Save to File. To copy the request

to the clipboard, click Copy to Clipboard. Then click Done to complete yourrequest.

22. E-mail your request or attach the saved file and send your request to thecertificate authority administrator.

Installing the server certificateAfter you have received the certificate from the certificate authority, install it bycompleting the following steps:1. Open the iPlanet Directory Server Console.2. Click the Tasks tab and then click Manage Certificates.3. Ensure that Server Certs is selected and then click Install.4. Do one of the following:

v To install the certificate from a file, select In this local file.v To paste the text in the window, select In the following encoded text block,

copy the text of the certificate, and then click Paste from Clipboard.5. Click Next.6. Verify that the certificate information is correct and click Next.7. In the This certificate will be named field, type a certificate name or accept the

default name, server-cert, and then click Next.8. Enter the token password and then click Done. If the process is successful, the

Manage Certificate panel is displayed and the server certificate name is listedunder the Server Certs tab.

9. Continue to “Enabling SSL access” on page 158.


Enabling SSL accessWhen you have exited the Certificate Setup Wizard, you are returned to theEncryption tab on the iPlanet Console 5.0 as shown:

1. Select Enable SSL.2. Check RSA Cipher Family.3. If you do not plan to require certificate-based client authentication, select Do

not allow client authentication.4. Click Save.5. Restart iPlanet Directory Server for changes to take effect.

Note: You have to type the trust database password each time the server isstarted.

SSL is now enabled on iPlanet Directory Server. Next, you need to enable SSLon the IBM SecureWay Directory client systems that will function as LDAPclients to iPlanet Directory Server.

See “Configuring the IBM SecureWay Directory client for SSL access” on page161.

Configuring OS/390 and z/OS SecureWay LDAP servers for SSL accessWhen Access Manager and LDAP services are not on the same protected network,it is recommended that you enable SSL communication between the LDAP serverand the clients that support Access Manager software. This protocol providessecure, encrypted communications between each server and client. Access Manageruses these communications channels as part of the process for makingauthentication and authorization decisions.

This section provides an example of how to set up server and client authenticationon a Windows NT platform using a self-signed certificate. This procedure requiresthe use of gsk5ikm, a graphical key management tool provided with IBM GlobalSecurity Toolkit (GSKit). GSKit is shipped on the IBM Tivoli Access Manager BaseCD for AIX, Solaris, and Windows platforms.


Before you begin enabling SSL, ensure that supported versions of GSKit andgsk5ikm are installed on both the LDAP server and any LDAP client systems thatwill be using SSL. In addition, keep in mind that you can create both the client andserver certificates on a Windows NT system and then copy the files to the requisiteservers. For detailed information about enabling SSL, see the productdocumentation that came with your LDAP server.

Create a key database file for the serverStart the key management tool (gsk5ikm). Then select Key Database File→Newand complete fields as shown:

Provide a database password when prompted. Note that it is not necessary to stashthe password or set a password expiration time.

Create a self-signed certificateTo create a new self-signed certificate and store it in the key database file, selectCreate→New Self-Signed Certificate and complete fields for your installation as


shown:

Note that this certificate is displayed in both the Personal Certificates section andSigner Certificates section of the key database file.

Store the server certificateThe next step is to extract your LDAP server’s certificate to a Base64-encodedASCII data file. Do this by highlighting the self-signed certificate that you createdand click Extract Certificate as shown:

Click Base64-encoded ASCII data as the data type and then type a certificate filename for the newly extracted certificate. Note that the certificate file’s extension is.arm. Type the location where you want to store the extracted certificate and clickOK. Next, copy this extracted certificate to the LDAP client system. This is neededwhen you add a signer certificate to the client key database file (as described onpage 7).

Add a security stanza to the LDAP configuration fileTo add a stanza to the LDAP configuration file, see “Sample LDAP configuration”on page 199 for example definitions for the stanza. Required entries to enable SSL

are as follows:


securePort integerSpecifies a port number for the LDAP server to communicate to secureclient requests.

security SSLSpecifies secure sockets layer (SSL) security.

sslKeyRingFile stringSpecifies the path to server key database file created in “Create a keydatabase file for the server” on page 159.

sslKeyRingFilePW stringSpecifies the password to the key database file created in “Creating a keydatabase file”.

sslCipherSpecs integerSpecifies the decimal value of the OR’ed hexadecimal codes for the ciphertypes that the server supports. 15104 is the union of all the cipher options.Available options are as follows:CipherHexadecimal ValueDecimal ValueRC4_MD5_US0x08002048TRIPLE_DES_SHA_US0x0100256DES_SHA_US0x0200512RC2_MD5_EXPORT0x10004096RC4_MD5_ESPORT0x20008192

Restart the LDAP serverFollow instructions in “Starting the server” on page 51.

Configuring the IBM SecureWay Directory client for SSL accessYou must first set up the LDAP server for SSL access before you set up the LDAPclient for SSL access. If you have not yet configured the LDAP server for SSLaccess, go to “Configuring the IBM SecureWay Directory server for SSL access” onpage 151.

Similar to creating a key database file for the server, you must create a keydatabase file on the client system. Note that in order for the client to authenticatethe LDAP server, the client must recognize the certificate authority (signer) thatcreated the LDAP server’s certificate. If the LDAP server is using a self-signedcertificate, the client must be enabled to recognize the system that generated theLDAP server’s certificate as a trusted root (certificate authority).

To configure the LDAP client for SSL access to the LDAP server, complete theinstructions in the following sections:v “Creating a key database file” on page 161v “Adding a signer certificate” on page 162v “Testing SSL access” on page 163

Creating a key database fileUse the gsk5ikm utility to create the key database file and the certificate. To createthe key database file and certificate (self-signed or signed), follow these steps:1. Ensure that GSKit and the gsk5ikm utility are installed on both the LDAP

server and any LDAP clients that will be using SSL.


2. Start the gsk5ikm utility, which is located in one of the following directories:

System Path






3. To create a new key database file, select Key Database File → New.4. Verify that the CMS key database file is the selected key database type.5. Type the information in the File Name and Location fields where you want

the key database file to be located. A key database file’s extension is.kdb.6. Click OK.7. Enter the key database file password, and confirm it.

Remember this password because it is required when the key database file isedited.

8. Accept the default expiration time, or change it to your organization’srequirements.

9. If you want the password to be masked and stored into a stash file, selectStash the password to a file.A stash file can be used by some applications so that the application does nothave to know the password to use the key database file. The stash file has thesame location and name as the key database file and has an extension of.sth.

10. Click OK. This completes the creation of the key database file. There is set ofdefault signer certificates. These signer certificates are the default certificateauthorities that are recognized.In order for the client to be able to authenticate the LDAP server, the clientmust recognize the certificate authority (signer) that created the LDAP server’scertificate. If the LDAP server is using a self-signed certificate, the client mustbe enabled to recognize the system that generated the LDAP server’scertificate as a trusted root (certificate authority).

11. After creating the key database file, change the file ownership of the keydatabase file to ivmgr. Use the appropriate operating system command forchanging file ownership. For example, on UNIX systems, enter the following:# chown ivmgr keyfile

Adding a signer certificateTo add a signer certificate after the key database file has been created, follow thesesteps:1. If you are using a self-signed certificate for the LDAP server, ensure that the

certificate that was extracted from the key database file in “Creating andextracting a self-signed certificate” on page 153 has been copied to the clientsystem. If it has not been copied, copy it now. Otherwise, ensure that youhave the certificate authority’s certificate which created your LDAP server’scertificate.

2. Click the Signer Certificates section of the client’s CMS key database file.3. Click Add.4. Click Base64-encoded ASCII data to set the data type.


5. Indicate the certificate’s file name and its location. The certificate file’sextension is usually.arm.

6. Click OK.7. Type a label for the signer certificate that you are adding. For example, you

can use the system name of the LDAP server for the label. If the LDAPserver’s certificate was created by a certificate authority, you can use thecertificate authority’s name as the label.

8. Click OK. The certificate is displayed in the client’s key database as a signercertificate.

9. Highlight the newly added signer certificate, and click View/Edit.10. Ensure that Set the certificate as a trust root is selected so that the certificate

is marked as a trusted root.If the LDAP server’s certificate was generated by a regular certificateauthority, be sure that the certificate authority is listed as a signer certificateand marked as a trusted root. If it is not, add the certificate authority’scertificate as a signer certificate and indicate that it is a trusted root.

The client is now able to establish an SSL session with the LDAP server.

Testing SSL accessTo test that SSL access has been enabled, enter the following command on theLDAP client:ldapsearch -h servername -Z -K client_keyfile -P key_pw-b "" -s base objectclass=*




client_keyfile The fully qualified path name of the generatedclient key ring.


This command returns the LDAP base information, which includes the suffixes onthe LDAP server.

During LDAP server configuration in “Configuring the IBM SecureWay Directoryserver for SSL access” on page 151, you chose an authentication method of eitherServer Authentication or Server and Client Authentication.v If you chose Server Authentication, the SSL setup is now complete.v If you chose Server and Client Authentication, go to “Configuring LDAP server

and client authentication”.

Configuring LDAP server and client authenticationDuring the configuration of the LDAP server to enable SSL access, as described in“Enabling SSL access” on page 154, you were prompted to choose either ServerAuthentication or Server and Client Authentication.

If you chose Server Authentication, SSL configuration is complete.


If you chose Server and Client Authentication, you must now establish acertificate for the client system. In this mode of authentication, the server requeststhe client’s certificate and uses it to authenticate the client’s identity.

To establish a certificate for the client system, complete the instructions in thefollowing sections:v “Creating a key database file” on page 164v “Obtaining a personal certificate from a certificate authority” on page 165v “Creating and extracting a self-signed certificate” on page 165v “Adding a signer certificate” on page 166v “Testing the SSL access” on page 167

Creating a key database fileIf you have not already created a client key database file, use the gsk5ikm utilityto create the key database file and the certificate. If you have already created a keydatabase file, go to “Obtaining a personal certificate from a certificate authority” onpage 165.

To create the key database file and certificate (self-signed or signed), follow thesesteps:1. Ensure that the GSKit and gsk5ikm are installed on both the LDAP server and

any clients that will be using SSL.2. Start the gsk5ikm utility, which is located in one of the following directories:

System Path





Windows C:\Program Files\IBM\GSK5\bin\ GSK5ikm.exe

3. Select Key Database File → New.4. Verify that the CMS key database file is the selected key database type.5. Type the information in the File Name and Location fields where you want

the key database file to be located. A key database file’s extension is.kdb.6. Click OK.7. Enter the key database file password, and confirm it. Remember this

password because it is required when the key database file is edited.8. Accept the default expiration time, or change it to your organization’s

requirements.9. If you want the password to be masked and stored into a stash file, select

Stash the password to a file.A stash file can be used by some applications so that the application does nothave to know the password to use the key database file. The stash file has thesame location and name as the key database file and has an extension of .sth.

10. Click OK.This completes the creation of the key database file. There is set of defaultsigner certificates. These signer certificates are the default certificateauthorities that are recognized.


11. After creating the key database file, change the file ownership of the keydatabase file to ivmgr. Use the appropriate operating system command forchanging file ownership. For example, on UNIX systems, enter the following:# chown ivmgr keyfile

Obtaining a personal certificate from a certificate authorityIf you plan to use a certificate from a certificate authority (such as VeriSign),instead of a self-signed certificate, you must request the certificate from thecertificate authority and then receive it after it has been completed.

If you plan to use a self-signed certificate, skip this section and go to “Creatingand extracting a self-signed certificate”.

To request and receive a certificate, follow these steps:1. Use gsk5ikm to request a certificate from a certificate authority and then

receive the new certificate into your key database file.2. Click the Personal Certificate Requests section of the key database file.3. Click New.4. To produce a request that can be sent to the certificate authority, complete the

information and then click OK.5. To install the certificate to your key database file after the certificate authority

returns it, click the Personal Certificates section and then click Receive.6. After you have the LDAP client’s certificate in the key database file, you can

add the certificate of the certificate authority, which created the client’scertificate to the LDAP server.

7. Continue to “Adding a signer certificate” on page 166.

Creating and extracting a self-signed certificateIf you obtained a certificate from a known certificate authority, as described in“Obtaining a personal certificate from a certificate authority”, skip this section andgo “Adding a signer certificate” on page 166.

To create a new self-signed certificate and store it into the key database file, followthese steps:1. Start the gsk5ikm utility, which is located in one of the following directories:

System Path






2. Select Create → New Self-Signed Certificate.3. Type a name in the Key Label field that GSKit can use to identify this new

certificate in the key database.For example, the label can be the system name of the LDAP client.

4. Accept the defaults for the Version field (X509 V3) and for the Key Size field.5. Either accept the default system name or enter a different distinguished name

in the Common Name field for this certificate.


6. Enter a company name in the Organization field.7. Complete any optional fields or leave them blank.8. Either accept the defaults for the Country field and 365 for the Validity

Period field or change them to suit your organization’s requirements.9. Click OK. GSKit generates a new public and private key pair and creates the

certificate.If you have more than one personal certificate in the key database file, GSKitqueries if you want this key to be the default key in the database. You canaccept one of them as the default. The default certificate is used at runtimewhen a label is not provided to select which certificate to use.This completes the creation of the LDAP client’s personal certificate. It isdisplayed in the Personal Certificates section of the key database file. Use themiddle bar of the key management utility to select between the types ofcertificates kept in the key database file.The certificate also is displayed in the Signer Certificates section of the keydatabase file. When you are in the Signer Certificates section of the keydatabase, verify that the new certificate is there.Next, you must extract your LDAP server’s certificate to a Base64-encodedASCII data file.

10. Use gsk5ikm to extract your LDAP server’s certificate to a Base64-encodedASCII data file.

11. Highlight the self-signed certificate that you just created.12. Click Extract Certificate.13. Click Base64-encoded ASCII data as the data type.14. Type a certificate file name for the newly extracted certificate. The certificate

file’s extension is usually.arm.15. Type the location where you want to store the extracted certificate and then

click OK.16. Copy this extracted certificate to the LDAP server system.

On the LDAP server, after the client’s personal certificate has been created andadded to the client’s key database file, the certificate authority that created thatclient certificate must be recognized as a signer certificate (trusted root).

Adding a signer certificateYou must perform this step on the LDAP server.

To add a signer certificate after the key database file has been created, follow thesesteps:1. Do one of the following:

v If you are using a self-signed certificate for the client, ensure that thecertificate that was extracted from the key database file in “Creating andextracting a self-signed certificate” on page 165 has been copied to theserver system. If it has not been copied, copy it now and skip the followingsteps.

v If the client certificate was created by a certificate authority, add thecertificate authority’s certificate as a trusted signer using the followingsteps.

2. Click the Signer Certificates section of the client’s CMS key database file.3. Click Add.


4. Click Base64-encoded ASCII data to set the data type.5. Indicate the certificate’s file name and its location. The certificate file’s

extension is usually.arm.6. Click OK.7. Type a label for the signer certificate that you are adding. For example, you

can use the system name of the LDAP client for the label or the name of thecertificate authority that generated the client’s certificate.

8. Click OK. The self-signed certificate is displayed in the client’s key databaseas a signer certificate.

9. Highlight the newly added signer certificate, and click View/Edit.10. Ensure that Set the certificate as a trust root is selected so that the certificate

is marked as a trusted root.If the LDAP client’s certificate was generated by a regular certificate authority,be sure that the certificate authority is listed as a signer certificate and markedas a trusted root. If it is not, add the certificate authority’s certificate as asigner certificate and indicate that it is a trusted root.The server is now able to establish an SSL session with the LDAP client.

11. Continue to “Testing the SSL access”.

Testing the SSL accessAfter the LDAP server recognizes the certificate authority that created the client’spersonal certificate, test SSL access using the following command on the LDAPclient:ldapsearch -h servername -Z -K client_keyfile -P key_pw -N \client_label -b "" -s base objectclass=*




client_keyfile The fully qualified path name of the generatedclient key ring.


client_label The label associated with the key, if any. This fieldis optional and is only needed if the LDAP serveris configured to perform both server and clientauthentication.

This command returns the LDAP base information, which includes the suffixes onthe LDAP server. Notice that the –N parameter indicates the label that wasspecified when the client’s personal certificate was added to the client’s keydatabase file.

Note: Do not specify the LDAP server’s signer certificate label. The –N option indicatesto GSKit which client certificate is sent to the server when requested. If nolabel is specified, then the default personal certificate is sent when the serverrequests the client’s certificate.

The SSL setup is now complete.



Chapter 9. Enabling Secure Sockets Layer for Lotus Domino

It is recommended that you enable Secure Sockets Layer (SSL) communicationbetween your Lotus Domino server and IBM SecureWay Directory clients thatsupport Access Manager software.

This chapter includes the following sections:1. “Creating the SSL key ring file”2. “Enabling SSL access”3. “Creating an IBM Tivoli Access Manager administrative user for Domino” on

page 170

Creating the SSL key ring fileTo support SSL on a Domino server, you must create a Domino server key ring filethat contains the server side digital certificate. To do so, follow these steps:1. Start the Notes client on the Domino server and then select File → Database →

Open. Open the Server Certificate Admin database on the Domino server.

Note: You must install the Domino Designer client on the Notes client system.2. Depending on the environment, do one of the following:

v Create SSL key ring and populate it with certificates

Complete the Create Key Ring, Create Certificate Request, Install RootCertificate and Install Certificate into Key Ring options.v Create a key ring with self-certified certificate for testing purpose

Double click on the Create Key Ring with Self-Certified Certificate option. Fillin the key ring file name and all other required fields. Click the Create KeyRing with Self-Certified Certificate button to complete the process.

Copy the key ring file and stash file to the following Domino server path:\Lotus\Domino\Data

Enabling SSL accessDomino supports client-side authentication only. To enable SSL, follow these steps:1. Start the Domino Administrator client and select the Configuration tab.2. Select the All Server Documents option under Server category on the left hand

side of the GUI. Open the server document where you want to configureLDAP.

3. Click Edit Server to prepare the server configuration update.4. Select the Ports tab on the server document.5. Select the Internet Ports tab and enter the Domino server key ring file name

created in “Creating the SSL key ring file”. Select Yes on Accept SSL SiteCertificates.

6. Select the Directory tab to update the LDAP configuration and then selectEnabled on SSL Port Status. Ensure that you indicate the following settings:v Set client certificate to No.v Set name & password to Yes.


v Set anonymous to either Yes or No.7. Click OK to update the server document. The LDAP SSL setup is complete.

If the Domino server’s certificate is not certified by the default Domino servertrusted certifier, you need to register the certifier in the Domino server key ringfile. To do so, follow these steps:1. Highlight the server document and pull down the Registration menu on the

right hand side.2. From the pull down menu, select Internet Certifier.3. Locate the Domino server key ring file and click Open to complete the Internet

Certifier registration process.4. To verify the registration above, select the People & Groups menu and click the

Certificates tab to verify that the new Domino server’s certifier has beeninserted in the Internet Certifiers list.

5. Save the server document.6. From the Domino server console, restart the LDAP server by entering the

following commands:tell ldap quit

load ldap

Creating an IBM Tivoli Access Manager administrative user for Domino1. From the Domino Administrator workspace GUI, pull down the People menu

on the right hand side.2. From the pull down menu, select Register.3. Select the Domino server’s Certifier ID (default location is

C:\Lotus\Domino\data).4. Type in the Certifier’s password (this was set up during server configuration).5. Select the Advanced check box and enter the Access Manager administrative

user information and password. For example:v First name: PD

v Last name: Daemons

v Password: password

6. Click ID Info to make sure the Notes ID file is stored in the Domino directory.7. Click the Add person button to add the Access Manager administrative user to

the Registration queue. The person document appears in the queue.8. Highlight the person document in the queue and click Register to add the user

to the Domino server.9. From the View pull down menu, click Refresh and verify that the Access

Manager user’s person document was created in the Domino server.


Appendix A. Upgrading to IBM Tivoli Access Manager

This chapter describes the following upgrade process procedures. For late-breakinginformation specific to the upgrade process, see the IBM Tivoli Release Notes fore-business, Version 3.9 on the Tivoli Customer Support Web site.

The following procedures listed in this chapter constitute the recommended stepsfor components at the time of publication.

Note that if you are attempting to upgrade your secure domain from a productversion earlier than 3.7.x, you must first upgrade to Tivoli SecureWay PolicyDirector, Version 3.7.1.

If you plan to upgrade from either a Version 3.7.1 or Version 3.8 policy server withan LDAP registry, you can choose to upgrade on the same policy server system oruse two systems—your current policy server system and a second, clean system forVersion 3.9. This two-system approach provides the ability to keep your currentpolicy server functioning as you set up and test a second Version 3.9 policy serversystem. If you encounter a problem when upgrading using two systems, yousimply take the Version 3.9 server offline.v Upgrading from Version 3.7.1 with DCE registry

– “Upgrading a Version 3.7.1 policy server with DCE” on page 173– “Upgrading other Version 3.7.1 systems with DCE” on page 176

v Upgrading from Version 3.7.1 with LDAP registry

– “Upgrading a Version 3.7.1 policy server with LDAP” on page 178– “Upgrading a Version 3.7.1 policy server with LDAP using two systems” on

page 181– “Upgrading other Version 3.7.1 systems with LDAP” on page 183

v Upgrading from Version 3.8 with LDAP registry

– “Upgrading a Version 3.8 policy server with LDAP” on page 186– “Upgrading a Version 3.8 policy server with LDAP using two systems” on

page 187– “Upgrading other Version 3.8 systems with LDAP” on page 189

Upgrade considerationsBefore upgrading Tivoli SecureWay Policy Director systems to IBM Tivoli AccessManager for e-business (Access Manager), Version 3.9, review the followingconsiderations:v Terminology update: The upgrade procedures listed in this appendix state Tivoli

SecureWay Policy Director when referring to Version 3.7.1 and Version 3.8. ForVersion 3.9, the Tivoli SecureWay Policy Director product was renamed to IBMTivoli Access Manager. In addition, the management server (PDMgrD) wasrenamed to policy server. This new term is used throughout all procedures in thischapter.

v As a standard precaution when upgrading between versions, make sure toperform a full system back up. Additionally, make sure to back up all TivoliSecureWay Policy Director servers before you begin. In addition, if you are


upgrading from an LDAP registry, it is recommended that you use LDAPcommands to back up and later restore LDAP data. For more information, seeyour LDAP product documentation.

v You are not required to upgrade all systems in your secure domain to a Version3.9 level. For a list of Version 3.7.1 and Version 3.8 systems that are backwardcompatible with the Version 3.9 policy server, see “IBM Tivoli Access Managercompatibility” on page 11.

v Upgrade does not support changing your registry type. For example, you cannotupgrade from an LDAP registry to a Domino registry.

v If upgrading a system with an existing Access Manager application installed, seethe application documentation posted on the Tivoli Support Web site foradditional requirements and recommendations during the upgrade process.

v To avoid having to perform multiple iterations of the upgrade, ensure that theadministrative user account for Tivoli SecureWay Policy Director (for example,sec_master) has permission over all ACLs before running the migrate37command.

v On UNIX systems only:– All commands are run as the root user.– The temporary directory is /tmp.– The installation path is /opt/PolicyDirector and /var/PolicyDirector.

v On Windows systems only:– Commands are run by a user included in the Administrator group.– The temporary directory is the value specified by the %TMP% variable. If the

%TMP% variable does not exist, the value specified by the %TEMP%variable is used. If neither of these variables are set, the system directory isthe temporary directory.

– The installation path varies and is dependent on the directory specifiedduring installation.

– The upgrade process from Version 3.7.1 involves the use of one or more of thefollowing migration commands.

Note: These commands are not required for Version 3.8 upgrades because thedatabase format has not changed from Version 3.8 to Version 3.9.

- migrate.conf—Contains configuration information used by the migrate37,migrate39, and pdupgrade commands.

- migrate37—Backs up critical Access Manager data on the policy serversystem. This command extracts data (ACLs, the object space, and so on)from your existing Version 3.7.1 installation and stores the data inXML-formatted output files (one file for each type of data).

- migrate39—Restores critical Access Manager data on the policy serversystem. This command extracts the data from the migrate37 output filesand restores the data to the Version 3.9 installation.

- pdbackup—Backs up, restores, and extracts data when you upgrade thepolicy server in multi-machine migrations.

- pdupgrade—Exports, imports, and restores Tivoli SecureWay PolicyDirector data. On Windows systems, this command is called automaticallyby InstallShield.


Upgrading from Version 3.7.1 with DCEDCE registry support was removed in Version 3.8 and subsequent releases.Therefore, the following instructions describe how to upgrade to Version 3.9,changing your DCE registry to an LDAP registry in the process.

Ensure that you follow the “Upgrading a Version 3.7.1 policy server with DCE” onpage 173 procedure first. In turn, the policy server upgrade process prompts you tofollow instructions in “Upgrading other Version 3.7.1 systems with DCE” onpage 176 to upgrade non-policy server systems in your secure domain.v “Upgrading a Version 3.7.1 policy server with DCE” on page 173v “Upgrading other Version 3.7.1 systems with DCE” on page 176

Upgrading a Version 3.7.1 policy server with DCEFollow these steps to migrate a Version 3.7.1 policy server with a DCE registry to aVersion 3.9 policy server with an LDAP registry:1. Install and configure a supported LDAP server to be used as the user registry

for Access Manager, Version 3.9.IBM SecureWay Directory server, Version 3.2.2, is shipped with AccessManager. For information about supported LDAP servers, see softwarerequirements in the IBM Tivoli Access Manager for e-business Release Notes.

2. From the IBM Tivoli Access Manager Base CD for your particular platform,copy the following files to the temporary directory on your policy serversystem:v migrate.conf

v migrate37 (migrate37.exe on Windows systems)v migrate39 (migrate39.exe on Windows systems)v pdupgrade (pdupgrade.exe on Windows systems)

Note: On Windows systems, the pdupgrade program is called automaticallyby InstallShield.

These files are located in the following directories:v For AIX:

cd_path/user/sys/inst.images/migrate

v For Solaris:cd_path/solaris/migrate

v For HP-UX:cd_path/hp/migrate

v For Windows:cd_path\windows\migrate

where cd_path is the path to your CD-ROM drive.3. Edit the migrate.conf file on your system to configure IBM Tivoli Access

Manager for your particular environment. For instructions, see “Editing themigration configuration file” on page 190.

4. Install all operating system patches needed by IBM Tivoli Access Manager 3.9and its prerequisite products. For information about prerequisite products andrequired operating system patches, see software requirements in the IBM TivoliAccess Manager for e-business Release Notes.

Appendix A. Upgrading to IBM Tivoli Access Manager 173

5. Stop Tivoli SecureWay Policy Director applications running on the system.However, do not stop the policy server, the authorization server, or WebSEAL.Perform any product-specific instructions for installed Tivoli SecureWay PolicyDirector applications.

6. Use the dce_login command to log in as the DCE administrative user(cell_admin).

7. Back up critical Access Manager data using the migrate37 command. Forinstructions, see “Backing up Access Manager data” on page 192.

Note: If data is not accessible by a single user ID, you might need to run themigrate37 command multiple times with different user IDs.

8. Before continuing to step 9, you must unconfigure components on AccessManager systems other than the policy server system Follow instructions in“Upgrading other Version 3.7.1 systems with DCE” on page 176 and thencomplete the remainder of this procedure.

9. Do one of the following:v On UNIX systems, enter the following command to back up configuration

information to the /var/PolDir directory:/tmp/pdupgrade -export

v On Windows systems, enter the following command to back upconfiguration information to the %TMP%\PD37 directory:%TMP%\pdupgrade -export

where %TMP% specifies the temporary directory.

Note: Messages might appear in the pdupgrade.log file, that is located in the%TMP% directory, indicating a failure to copy files. You can ignorethese messages. The files are copied automatically when the pdupgradecommand is run manually.

10. On UNIX systems only, use the iv script installed with Tivoli SecureWayPolicy Director, Version 3.7.1 to stop all Tivoli SecureWay Policy Directorservices:For AIX systems, enter the following:/etc/iv/iv stop

For HP-UX systems, enter the following:/sbin/init.d/iv stop

For Solaris systems, enter the following:/etc/init.d/iv stop

Note: To ensure that all Tivoli SecureWay Policy Director services andapplications are stopped, issue the ps command. If any TivoliSecureWay Policy Director service or application is still running, issuethe kill command.

11. Install IBM Global Security Toolkit, Version 5.0.4.67 and upgrade to IBMSecureWay Directory client, Version 3.2.2, e-fix 1. For instructions, see the″Using native installation″ section in the chapter for your particular platform.Removal of previous IBM Global Security Toolkit product versions is notrequired. Once you have completed the native installation steps, return to thisprocedure to ensure successful procedure completion.Notes:


v If during the GSKit upgrade you are prompted to reboot, make sure toreboot and then continue with this procedure.

v Access Manager supports GSKit, Version 5.0.4.67 or later. Although Version5 is not compatible with Version 4, these versions can coexist on the samesystem.

12. To uninstall Tivoli SecureWay Policy Director, Version 3.7.1, do one of thefollowing:v For AIX systems, skip to step 13.v For Windows systems, use the pdconfig command to unconfigure

components and then click the Add/Remove Programs icon to remove thefollowing Version 3.7.1 packages in this order:– PDAuthADK– PDAcld– PDMgr– PDRTE

v On HP-UX systems, following these steps:

Note: It is not necessary to unconfigure components first.a. Enter the following:

rm -f /opt/PolicyDirector/.configure/*

b. To remove packages, use the swremove command as follows:swremove -x enforce_dependencies=false package_name

where package_name is one of the following in this order:– PDAuthADK– PDAcld– PDMgr– PDRTE

Note: You can use the swlist command to match output packagenames.

c. To ensure that Tivoli SecureWay Policy Director, Version 3.7.1 isuninstalled, enter the following:rm -fR /opt/PolicyDirector

v On Solaris systems, follow these steps:

Note: It is not necessary to unconfigure components first.a. Enter the following:


b. To remove packages, use the pkgrm command as follows:pkgrm package_name

where package_name is one of the following in this order:– PDAuthADK– PDAcld– PDMgr– PDRTE


The pkgrm command prompts if you want to continue removing thecomponent even though it is still configured. Enter yes to continue. Ifyou have dependencies installed, such as WebSEAL, you are promptedif you want to uninstall the Tivoli SecureWay Policy Director basecomponent even though there are applications dependent on it. Enteryes to continue.

Note: You can use the pkinfo command to match output packagenames.


13. Install and configure Access Manager, Version 3.9, components. Forinstructions, see the ″Using native installation″ section in the chapter for yourparticular platform.

14. Restore previously backed up data. For instructions, see “Restoring AccessManager data” on page 194.A working Access Manager Version 3.9, is now ready. Verify that you canlogin to the system, and that all of your data was migrated successfully.

15. Start any Access Manager applications and perform any necessaryproduct-specific tasks.

16. Assign new LDAP passwords to each user after the migration. DCE userpasswords are not migrated to LDAP.

Upgrading other Version 3.7.1 systems with DCEEnsure that you upgrade the policy server before upgrading any other TivoliSecureWay Policy Director systems. The policy server upgrade procedure describedin “Upgrading a Version 3.7.1 policy server with DCE” on page 173 will instructyou when to upgrade other Version 3.7.1 systems (as described in this section).1. For systems with WebSEAL installed, follow upgrade instructions described in

IBM Tivoli Access Manager WebSEAL Installation Guide, Version 3.9.2. Unconfigure Tivoli SecureWay Policy Director components on all systems,

except for systems with an authorization server installed. If you have anauthorization server installed on a system, you must unconfigure thiscomponent and its associated runtime component after all Tivoli SecureWayPolicy Server components have been unconfigured on all systems in yoursecure domain (excluding the policy server system). If the configuration fileshave been customized, save the configuration files to refer to later.





v Access Manager supports GSKit, Version 5.0.4.67 or later. Although Version 5is not compatible with Version 4, these versions can coexist on the samesystem.

5. To uninstall Tivoli SecureWay Policy Director, Version 3.7.1, do one of thefollowing:v For AIX systems, skip to step 6.v For Windows systems, click the Add/Remove Programs icon to remove the

following Version 3.7.1 packages in this order:– PDAuthADK– PDAcld– PDRTE

v On HP-UX systems, following these steps:a. Enter the following:


b. To remove packages, use the swremove command as follows:swremove -x enforce_dependencies=false package_name

where package_name is one of the following in this order:– PDAuthADK– PDAcld– PDRTE

Note: You can use the swlist command to match output package names.c. To ensure that Tivoli SecureWay Policy Director, Version 3.7.1 is

uninstalled, enter the following:rm -fR /opt/PolicyDirector

v On Solaris systems, follow these steps:a. Enter the following:



where package_name is one of the following in this order:– PDAuthADK– PDAcld– PDRTE

The pkgrm command prompts if you want to continue removing thecomponent even though it is still configured. Enter yes to continue. If youhave dependencies installed, such as WebSEAL, you are prompted if youwant to uninstall the Tivoli SecureWay Policy Director base componenteven though there are applications dependent on it. Enter yes tocontinue.

Note: You can use the pkginfo command to match output packagenames.



6. Install and configure Access Manager, Version 3.9, components. For instructions,see the ″Using native installation″ section in the chapter for your particularplatform.

7. Start any Access Manager applications and perform any product-specific tasks.

Upgrading from Version 3.7.1 with LDAPThis section contains the following procedures:v “Upgrading a Version 3.7.1 policy server with LDAP”v “Upgrading a Version 3.7.1 policy server with LDAP using two systems” on

page 181v “Upgrading other Version 3.7.1 systems with LDAP” on page 183

Upgrading a Version 3.7.1 policy server with LDAPFollow these steps to migrate a Version 3.7.1 policy server with an LDAP registryto a Version 3.9 policy server with an LDAP registry. Note that this procedure isfor upgrading on the same policy server system. To upgrade your policy serverusing multiple systems, see “Upgrading a Version 3.7.1 policy server with LDAPusing two systems” on page 181.1. From the IBM Tivoli Access Manager Base CD for your particular platform,

copy the following files to the temporary directory on your policy serversystem:v migrate.conf

v migrate37 (migrate37.exe on Windows systems)v migrate39 (migrate39.exe on Windows systems)v pdupgrade (pdupgrade.exe on Windows systems)







where cd_path is the path to your CD-ROM drive.2. Edit the migrate.conf file on your system to configure IBM Tivoli Access

Manager for your particular environment. For instructions, see “Editing themigration configuration file” on page 190.




5. Use the dce_login command to log in as the DCE administrative user(cell_admin). Note that Version 3.7.1 required DCE even if the user registrywas not DCE.

6. Back up critical user registry information using the migrate37 command. Forinstructions, see “Backing up Access Manager data” on page 192.Notes:

v If information is not accessible by a single user ID, you might need to runthe migrate37 command multiple times with different user IDs.

v It is not necessary to back up users and groups if you plan to use the sameLDAP server from the Version 3.7.1 installation.



v On Windows systems, enter the following command to back upconfiguration information to the %TMP%\Pol Dir directory:%TMP%\pdupgrade -export


Note: Messages might appear in the pdupgrade.log file, that is located in the%TMP% directory, indicating a failure to copy files. You can ignorethese messages. The files are copied automatically when the pdupgradecommand is run manually.

8. Stop all Tivoli SecureWay Policy Director services by doing one of thefollowing:v On Windows systems, select Start → Settings → Control Panel →

Administrative Tools (Windows 2000 only) and then double-click theServices icon. Stop all Tivoli SecureWay Policy Director services running onthe local system, including applications, such as WebSEAL.

v On UNIX systems, use the iv script installed with Tivoli SecureWay PolicyDirector, Version 3.7.x.For AIX systems, enter the following:/etc/iv/iv stop



Note: To ensure that all Tivoli SecureWay Policy Director services andapplications are stopped, issue the ps command. If any Tivoli SecureWayPolicy Director service or application is still running, issue the killcommand.

9. Install IBM Global Security Toolkit, Version 5.0.4.67 and upgrade to IBMSecureWay Directory client, Version 3.2.2, e-fix 1. For instructions, see the″Using native installation″ section in the chapter for your particular platform.


Removal of previous IBM Global Security Toolkit product versions is notrequired. Once you have completed the native installation steps, return to thisprocedure to ensure successful procedure completion.Notes:



v If the IBM SecureWay Directory client is on the same system as the IBMSecureWay Directory server, it will be necessary to upgrade your server. Forinformation about upgrading the server, see the IBM SecureWay Directorydocumentation.

10. For AIX and Windows users, skip to Step 11. On HP-UX and Solaris systemsonly, you must uninstall Tivoli SecureWay Policy Director, Version 3.7.1, basepackages. The base packages are listed as follows:v PDRTEv PDMgrv PDAuthADKv PDAcld

On HP-UX systems, enter the following commands in this order:a. Enter the following:


b. Use swlist or similar command and match output package names to thoselisted.

c. To remove packages, use the swremove command as follows:swremove -x enforce_dependencies=false package_name

d. To ensure that Tivoli SecureWay Policy Director, Version 3.7.1 isuninstalled, enter the following:rm -fR /opt/PolicyDirector

On Solaris systems, enter the following commands in this order:a. Enter the following:



The pkgrm command prompts if you want to continue removing thecomponent even though it is still configured. Enter yes to continue. If youhave dependencies installed, such as WebSEAL, you are prompted if youwant to uninstall the Tivoli SecureWay Policy Director base componenteven though there are applications dependent on it. Enter yes to continue.

Note: You can use pkginfo to match output package names.c. To ensure that Tivoli SecureWay Policy Director, Version 3.7.1 is

uninstalled, enter the following:rm -fR /opt/PolicyDirector

11. Make sure your LDAP server is running and then install IBM Tivoli AccessManager, Version 3.9, components. For instructions, see the ″Using nativeinstallation″ section in the chapter for your particular platform.


12. Restore previously backed up information. For instructions, see “RestoringAccess Manager data” on page 194.A working Access Manager Version 3.9, is now ready. Verify that you canlogin to the system, and that all of your data was migrated successfully.


Notes:

a. DCE user passwords do not get migrated to the LDAP user registry.Ensure that you reset the user passwords.

b. When the PDRTE install package is upgraded from version 3.7.1 to version3.9 on the AIX platform, all dependent applications on that system shouldremove their local cached copy of the Access Manager policy databasebefore attempting to start their application.

Upgrading a Version 3.7.1 policy server with LDAP using twosystems

Follow these steps to upgrade to Version 3.9 using two systems. This procedureallows your 3.7.1 policy server to continue functioning while you set up your new3.9 policy server on a separate system.1. From the IBM Tivoli Access Manager Base CD for your particular platform,

copy the following files to a temporary directory on your existing 3.7.1 policyserver system:v migrate.conf

v migrate37 (migrate37.exe on Windows systems)v migrate39 (migrate39.exe on Windows systems)v pdbackup (pdbackup.exe on Windows systems)v mig37to39.lst

v pdupgrade (pdupgrade.exe on Windows systems)







where cd_path is the path to your CD-ROM drive.2. Stop all Tivoli SecureWay Policy Director services on your existing 3.7.1 policy

server by doing one of the following:v On Windows systems, select Start → Settings → Control Panel →



v On UNIX systems, use the iv script installed with Tivoli SecureWay PolicyDirector, Version 3.7.x.For AIX systems, enter the following:/etc/iv/iv stop




3. Change directories on your existing 3.7.1 policy server to the temporarydirectory where you copied the files from the IBM Tivoli Access Manager BaseCD. To back up Access Manager data on the current policy server, use thepdbackup command. For example, enter the following command:pdbackup -action backup -file archive_name -list mig37to39.lst -path path

where archive_name is the Policy Director data archive file name on UNIX orthe archive directory name on Windows and path is the path where thearchive file or archive directory is created. Once the pdbackup command iscomplete, a Policy Director data archive file or data archive directory will beproduced in the path specified.

Note: For information about this command, see “pdbackup” on page 226.4. Restart the policy server daemon (ivmgrd) or service on the existing 3.7.1

policy server by doing one of the following:v On Windows systems, select Start → Settings → Control Panel →

Administrative Tools (Windows 2000 only) and then double-click theServices icon. Start all Tivoli SecureWay Policy Director services running onthe local system, including applications, such as WebSEAL.

v On UNIX systems, use the iv script installed with Tivoli SecureWay PolicyDirector, Version 3.7.x.For AIX systems, enter the following:/etc/iv/iv start

For HP-UX systems, enter the following:/sbin/init.d/iv start

For Solaris systems, enter the following:/etc/init.d/iv start

5. Copy the archive produced by the pdbackup command from the existing 3.7.1policy server to the new 3.9 policy server. If you are using a Windows system,copy the archive directory and all of its contents to the new 3.9 policy server.

Note: The new 3.9 policy server must be a clean system. Do not use anexisting system.

6. Install all operating system patches needed by IBM Tivoli Access Manager 3.9and its prerequisite products. For information about prerequisite products and


required operating system patches, see software requirements in the IBM TivoliAccess Manager for e-business Release Notes.

7. Make sure your LDAP server is running and then install Access Manager,Version 3.9, and its prerequisites on the new 3.9 policy server. For instructions,see the ″Using native installation″ section in the chapter for your particularplatform.

8. To extract registry data to the new 3.9 policy server, use the pdbackupcommand. For example, enter the following:pdbackup -action extract -path restore_directory -file archive_name

where restore_directory is the temporary directory on the new 3.9 policyserver you want to extract your archive data to and archive_name is the PolicyDirector data archive file or archive directory name.

Note: For information about this command, see “pdbackup” on page 226.9. Configure the runtime environment on the new 3.9 policy server. When

prompted for an LDAP server, specify the name of the LDAP server that isused by the existing 3.7.1 policy server.

10. Configure the new 3.9 policy server. When prompted if you want to configurethe policy for migration purposes, select yes and enter the restore_directoryspecified by the –path option in Step 8.

Note: If you make database changes or updates before you complete thisprocedure, you will need to repeat Steps 10 - 12 to ensure that you havebacked up the latest version of your database.

11. If upgrading from a 3.7.1 policy server, your original users are ready but allother data needs to be backed up. On the existing 3.7.1 policy server, run themigrate tool to back up the critical Access Manager data. For instructions, see“Backing up Access Manager data” on page 192.

12. Copy the XML files created in Step 11 to the new 3.9 policy server.13. Run the migrate tool to restore the Access Manager data. For instructions, see

“Restoring Access Manager data” on page 194.14. Continue to the next section, “Upgrading other Version 3.7.1 systems with

LDAP”, to upgrade other 3.7.1 systems. After that is accomplished, completethe procedure in “Retiring the Tivoli SecureWay Policy Director, Version 3.7.1,policy server” on page 186 to retire your 3.7.1 policy server.

Upgrading other Version 3.7.1 systems with LDAPFollow these steps to migrate Tivoli SecureWay Policy Director systems (other thanthe policy server) to Access Manager, Version 3.9:

Note: For all platforms, ensure that you upgrade the authorization server after allother base systems have been upgraded.

1. From the IBM Tivoli Access Manager Base CD for your particular platform,copy the following files to the temporary directory on your policy serversystem:v migrate.conf

v pdupgrade (pdupgrade.exe on Windows systems)


These files are located in the following directories:


v For AIX:cd_path/user/sys/inst.images/migrate




where cd_path is the path to your CD-ROM drive.2. Edit the migrate.conf file on your system to configure Tivoli SecureWay

Policy Director for your particular environment. For instructions, see “Editingthe migration configuration file” on page 190.



5. Use the dce_login command to log in as the DCE administrative user(cell_admin). Note that Version 3.7.1 required DCE even if the user registrywas not DCE.



v On Windows systems, enter the following command to back upconfiguration information to the %TMP%\Pol Dir directory:%TMP%\pdupgrade -export


Note: Messages might appear in the pdupgrade.log file, that is located inthe %TMP% directory, indicating a failure to copy files. You canignore these messages. The files are copied automatically when thepdupgrade command is run manually.

7. Stop all Tivoli SecureWay Policy Director services by doing one of thefollowing:v On Windows systems, select Start → Settings → Control Panel →


v On UNIX systems, use the iv script installed with Tivoli SecureWay PolicyDirector, Version 3.7.1.– For AIX systems, enter the following:

/etc/iv/iv stop

– For HP-UX systems, enter the following:/sbin/init.d/iv stop

– For Solaris systems, enter the following:


/etc/init.d/iv stop




v Access Manager supports GSKit, Version 5.0.4.67 or later. Although Version5 is not compatible with Version 4, these versions can coexist on the samesystem.


9. For AIX and Windows users, skip to step 10. On HP-UX and Solaris systemsonly, you must uninstall Tivoli SecureWay Policy Director, Version 3.7.1, basepackages. The base packages are listed as follows:v PDRTEv PDMgrv PDAuthADKv PDAcld

On HP-UX systems, enter the following commands in this order:a. Enter the following:


b. Use swlist or similar command and match output package names to thoselisted.

c. To remove packages, use the swremove command as follows:swremove -x enforce_dependencies=false package_name


On Solaris systems, enter the following commands in this order:a. Enter the following:


b. Use pkginfo or similar command and match output package names tothose listed.

c. To remove packages, use the pkgrm command as follows:pkgrm package_name

The pkgrm command prompts if you want to continue removing thecomponent even though it is still configured. Enter yes to continue. If you


have dependencies installed, such as WebSEAL, you are prompted if youwant to uninstall the Tivoli SecureWay Policy Director base componenteven though there are applications dependent on it. Enter yes to continue.


10. Make sure your LDAP server is running and then install IBM Tivoli AccessManager, Version 3.9, components. For instructions, see the ″Using nativeinstallation″ section in the chapter for your particular platform.


Note: When the PDRTE install package is upgraded from version 3.7.1 toversion 3.9 on the AIX platform, all dependent applications on thatsystem should remove their local cached copy of the Access Managerpolicy database before attempting to start their application.

Retiring the Tivoli SecureWay Policy Director, Version 3.7.1,policy server

Follow these steps to retire an existing Tivoli SecureWay Policy Director 3.7.1policy server once its data, clients, and servers have been successfully migrated toa new IBM Tivoli Access Manager 3.9 policy server:1. Copy the following file from the Version 3.9 policy server to a temporary

directory on the Version 3.7.1 policy server:v On UNIX systems: opt/PolicyDirector/sbin/pdmgr_ucfv On Windows systems: pd_install_path/sbin/pdmgr_ucf.exe

where pd_install_path is the Policy Director installation path.2. On the Version 3.7.1 policy server, run the pdmgr_ucf (pfmgr_ucf.exe on

Windows) executable.3. Uninstall Tivoli SecureWay Policy Director, Version 3.7.1. Refer to your Tivoli

SecureWay Policy Director, Version 3.7.1 documentation for uninstallationprocedures.

Note: Do not unconfigure the Version 3.7.1 policy server at any time during theupgrade process. Unconfiguration of the Version 3.7.1 policy servercauses the upgrade process to fail.

Upgrading from Version 3.8 with LDAPThis section includes the following procedures. Note that migration commands arenot required since the database format has not changed from Version 3.8 to Version3.9.v “Upgrading a Version 3.8 policy server with LDAP”v “Upgrading a Version 3.8 policy server with LDAP using two systems” on

page 187v “Upgrading other Version 3.8 systems with LDAP” on page 189

Upgrading a Version 3.8 policy server with LDAPFollow these steps to upgrade your system to Version 3.9.1. Stop all Tivoli SecureWay Policy Director services by doing one of the

following:


v On Windows systems, select Start → Settings → Control Panel →Administrative Tools (Windows 2000 only) and then double-click theServices icon. Stop all Tivoli SecureWay Policy Director services running onthe local system, including applications, such as WebSEAL.

v On UNIX systems, use the pd_start command installed with TivoliSecureWay Policy Director, Version 3.8. For example, enter the following:pd_start stop



3. Install IBM Global Security Toolkit, Version 5.0.4.67 and upgrade to IBMSecureWay Directory client, Version 3.2.2 with e-fix 1. For instructions, see the″Using native installation″ section in the chapter for your particular platform.Removal of previous IBM Global Security Toolkit product versions is notrequired. Once you have completed the native installation steps, return to thisprocedure to ensure successful procedure completion.Notes:



v If the IBM SecureWay Directory client is on the same system as the IBMSecureWay Directory server, it is necessary to upgrade your server. Forinformation about upgrading the server, see the IBM SecureWay Directorydocumentation.

4. To back up critical Policy Director information on the current policy server, usethe pdbackup command. For example, enter the following:pdbackup -action backup -file archive_name -list /path/pdbackup.lst

where archive_name is the Policy Director data archive file name on UNIX orthe archive directory name on Windows and /path/ is the fully qualified pathto where your pdbackup.lst file exists.

Note: For more information, see “pdbackup” on page 226.5. Make sure your LDAP server is running and then install Access Manager,

Version 3.9, components. For instructions, see the native installation procedurein the chapter for your particular platform.

6. Make sure your Access Manager policy server is running. Start any AccessManager applications and perform any necessary product-specific tasks.

Upgrading a Version 3.8 policy server with LDAP using twosystems

Follow these steps to upgrade to Version 3.9 using two systems. This procedureallows your policy server to continue functioning while you set up your newVersion 3.9 policy server on a separate system.


1. Stop all Tivoli SecureWay Policy Director services on your existing 3.8 policyserver by doing one of the following:v On Windows systems, select Start→Settings →Control Panel →


v On UNIX systems, enter the following:pd_start stop

Note: To ensure that all Tivoli SecureWay Policy Director services andapplications are stopped, issue the ps command. If any TivoliSecureWay Policy Director service or application is still running,issue the kill command.

2. To back up critical Access Manager information on the existing 3.8 policyserver, use the pdbackup command. For example, enter the following:pdbackup -action backup -file archive_name -list mig38to39.lst -path path

where archive_name is the Policy Director data archive file name on UNIX orthe archive directory name on Windows and path is the path where thearchive file or archive directory is created. Once the pdbackup command iscomplete, a Policy Director data archive file or data archive directory will beproduced in the path specified.

Note: For information about this command, see “pdbackup” on page 226.3. Restart the policy server daemon (pdmgrd) or service on the existing 3.8 policy

server by doing one of the following:v On Windows systems, select Start → Settings → Control Panel →

Administrative Tools (Windows 2000 only) and then double-click theServices icon. Start all Tivoli SecureWay Policy Director services running onthe local system, including applications, such as WebSEAL.

v On UNIX systems, enter the following:pd_start start

4. Copy the archive produced by the pdbackup command from the existing 3.8policy sever to the new 3.9 policy server. If you are using a Windows system,copy the archive directory and all of its contents to the new 3.9 policy server.

Note: The new 3.9 policy server must be a clean system. Do not use anexisting system.


6. Make sure your LDAP server is running and then install Access Manager,Version 3.9, and its prerequisites on the new 3.9 policy server. For instructions,see the ″Using native installation″ section in the chapter for your particularplatform.

7. To extract registry data to the new 3.9 policy server, use the pdbackupcommand. For example, enter the following:pdbackup -action extract -path restore_directory -file archive_name

where restore_directory is the temporary directory on the new 3.9 policyserver you want to extract your archive data to and archive_name is the PolicyDirector data archive file or archive directory name.


Note: For information about this command, see “pdbackup” on page 226.8. Configure the runtime environment on the new 3.9 policy server. When

prompted for an LDAP server, specify the name of the LDAP server that isused by the existing 3.8 policy server.

9. Configure the new 3.9 policy server. When prompted if you want to configurethe policy for migration purposes, select yes and enter the restore_directoryspecified by the –path option in Step 7.

10. Your system is ready. Run pdadmin and query both the ACL database and theuser registry to verify their status.

11. If you have made updates or changes to your database during the migrationprocess, you will need to copy the database files from the 3.8 policy server tothe new 3.9 policy server. The locations of the files to copy are as follows:v On UNIX systems: /var/PolicyDirector/db/master_authzn.dbv On Windows systems:installdir\db\master_authzn.db

12. Continue to the next section, “Upgrading other Version 3.8 systems withLDAP”, to upgrade other 3.8 systems. After that is accomplished, complete theprocedure in “Retiring the Tivoli SecureWay Policy Director 3.8 Policy Server”on page 190 to retire your 3.8 policy server.

Upgrading other Version 3.8 systems with LDAPFollow these steps to migrate Tivoli SecureWay Policy Director systems (other thanthe policy server) to Access Manager, Version 3.9:1. Stop Access Manager applications and services running on the system and

perform any product-specific instructions. To stop all applications and services,do one of the following:v On Windows systems, select Start → Settings → Control Panel →


v On UNIX systems, use the pd_start command installed with TivoliSecureWay Policy Director, Version 3.8. For example, enter the following:pd_start stop








4. To back up critical Policy Director information on the current policy server, usethe pdbackup command. For example, enter the following:pdbackup -action backup -file archive_name -list /full_path/pdbackup.lst

where archive_name is the Policy Director data archive file name on UNIX orthe archive directory name on Windows and /full_path/ is the full path towhere your pdbackup.lst file exists.

Note: For information about this command, see “pdbackup” on page 226.5. Make sure your LDAP server is running and then install Access Manager,

Version 3.9, components. For instructions, see the native installation procedurein the chapter for your particular platform.

6. Start any Access Manager applications and perform any product-specific tasks.

Retiring the Tivoli SecureWay Policy Director 3.8 Policy ServerFollow these steps to retire an existing Tivoli SecureWay Policy Director 3.8 policyserver once its data and client/server has been successfully migrated to a new IBMTivoli Access Manager, Version 3.9, policy server:1. Copy the following file from the Version 3.9 policy server to a temporary

directory on the Version 3.8 policy server:v On UNIX systems: opt/PolicyDirector/sbin/pdmgr_ucfv On Windows systems: pd_install_path/sbin/pdmgr_ucf.exe

where pd_install_path is the Policy Director installation path.2. On the Version 3.8 policy server, run the pdmgr_ucf (pfmgr_ucf.exe on

Windows) executable.3. Uninstall Tivoli SecureWay Policy Director, Version 3.8. Refer to your Tivoli

SecureWay Policy Director, Version 3.8, documentation for uninstallationprocedures.

Note: Do not unconfigure the Version 3.8 policy server at any time during theupgrade process. Unconfiguration of the Version 3.8 policy server causethe upgrade process to fail.

Editing the migration configuration fileAccess Manager provides a migration configuration file template, located in theplatform/migrate directory on the IBM Tivoli Access Manager Base CD for yourparticular platform. This file, named migrate.conf, serves as a guide for the formatand content of the required configuration items.

You must copy this file to your system and edit it appropriately in your ownsecure domain. Following is an example of a typical migration configuration file:## migration tool configuration file#[ldap]


domain = o=tivoli,c=usadmin-dn = cn=useradmin-pwd = userpdadmin-login = sec_masterpdadmin-pwd = TivoliSystemsdce-admin-name = cell_admindce-admin-pwd = celluser-reg-host = foo.bar.comuser-reg-hostport = 389user-reg-hostsslport = 636ssl-enabled = yesssl-keyfile = /opt/ibm/gsk5/bin/ldap.kdbssl-keyfile-dn = cn=tivolissl-keyfile-pwd = password

### HISTORY# $Log: $## $EndLog$

where:

domain Provides the base domain under which all migrated users andgroups reside. Tivoli SecureWay Policy Director uses this domainvalue in the construction of distinguished names for user andgroup entries. This entry is required.

For DCE, this suffix is the suffix under which the Tivoli SecureWayPolicy Director, Version 3.7.1, DCE users were added whenmigrating from a DCE registry and restoring to an LDAP registry.

For LDAP-migrated users, the migrate37 command handlesmultiple suffixes for data. When migrating from an LDAP registryand restoring to an LDAP registry, you do not need to specify themultiple suffixes.

admin-dn Provides the distinguished name of the LDAP databaseadministrator. This name is the same name that was specifiedduring the installation of the LDAP server. Typically, theadministrator’s distinguished name is cn=root for Tivoli SecureWayPolicy Director installations. This entry is required.

admin-pwd Specifies the password of the LDAP database administrator. Thisplain text file containing the password must be protected andavailable only to appropriate users and groups. This entry isrequired.

pdadmin-loginSpecifies the administrative user account for Tivoli SecureWayPolicy Director, for example, sec_master. This entry is required.

Attention: You must ensure that this user account has controlpermission over all ACLs. Otherwise, the migration command doesnot have permission to successfully back up all Tivoli SecureWayPolicy Director information.

pdadmin-pwd Specifies the password of the administrative user account for TivoliSecureWay Policy Director. This entry is required.

dce-admin-nameSpecifies the DCE administrator for the installation being migrated.


The DCE administrative user is a special type of user that TivoliSecureWay Policy Director uses only in certain administrative roles.Do not migrate this type of user from the DCE registry to theLDAP registry.

Because the migrate39 command cannot determine which user isthe administrative user without assistance, you must change thedefault name, cell_admin, to match the actual administrative userfor the installation being migrated. This entry is required.

dce-admin-pwdSpecifies the password of the DCE administrator. This entry isrequired.

user-reg-host Specifies the LDAP server used by Tivoli SecureWay PolicyDirector, Version 3.9. This entry is required.

user-reg-hostportSpecifies the LDAP server port. This entry is required.

user-reg-hostsslportSpecifies the LDAP server SSL port. This entry is required.

ssl-enabled Specifies whether Secure Sockets Layer (SSL) communications areenabled (yes) or disabled (no) on this system. If SSL is enabled,you also can specify the following options:

ssl-keyfileSpecifies the LDAP client key file. This entry is required.

ssl-keyfile-dnSpecifies the distinguished name in the key file. This entryis required.

ssl-keyfile-pwdSpecifies the password for the key file. This entry isrequired.

Backing up Access Manager dataBefore you back up Access Manager data on the policy server, ensure that thefollowing conditions are met:v Verify that the administrative user account for Tivoli SecureWay Policy Director

(for example, sec_master) has permission over all ACLs. Otherwise, themigrate37 command does not have permission to successfully back up all TivoliSecureWay Policy Director information.

v On Windows systems only, ensure that you also specify the –r option whenbacking up Tivoli SecureWay Policy Director information. For example, includethe following:-r "C:\Program Files\Tivoli\Policy Director\ivmgrd\lib\ivmgrd.conf"

where C:\Program Files\Tivoli\Policy Director\ivmgrd\lib is the pathspecified during Tivoli SecureWay Policy Director, Version 3.7.1 installation. Forreference information on migrate37 and migrate39 commands, see Appendix D,“Installation commands” on page 219.

v If you are upgrading from an LDAP registry only, you also must specify the –dldap option.


To back up data from a system with Tivoli SecureWay Policy Director, Version3.7.1, installed, follow these steps:

Note: It is not necessary to back up data from a system with Tivoli SecureWayPolicy Director, Version 3.8.

1. To back up access control list data, including permission actions and actiongroups, and protected object policy (POP) information, enter the followingcommand:migrate37 -t backup -s acls -f acls.xml

where acls.xml is the name of the file where access control list information isstored.

Note: Make sure that you run the migrate37 command from the temporarydirectory on the policy server system.

2. To back up object spaces and the objects that they contain, enter the followingcommand:migrate37 -t backup -s obj -f object.xml

where object.xml is the name of the file where all nondefault (user created)objects are stored.

3. If you are migrating from a DCE registry only, back up user and groupinformation by entering the following command:migrate37 -t backup -s user -f user.xml

where user.xml is the name of the file where user and group information isstored.

Notes:

v If you plan to use an existing LDAP server for the Version 3.9 installation,you do not have to back up users and groups. User password data also ispreserved.

v If you plan to install a new LDAP server, you must use LDAP commands(not migrate37) to back up user and group information.

4. To back up Global Sign-On (GSO) information (if installed), enter the followingcommand:migrate37 -t backup -s gso -f gso.xml

where gso.xml is the name of the file where GSO information is stored.5. To back up local mode authorization API server data for each configured

server, enter the following command:migrate37 -t backup -s server -f server.xml

where server.xml is the name of the file where server data is stored.6. For WebSEAL product installations only, enter the following to back up

WebSEAL junction data:migrate37 -t backup -s webseal -f jct_backup.xml

Notes:

v WebSEAL junction information is restored automatically by the WebSEALupgrade process. The WebSEAL process looks specifically for the jct_backupfile in the temporary directory on your system. For more information, see theIBM Tivoli Access Manager WebSEAL Installation Guide, Version 3.9.


v If the migrate37 command does not back up all WebSEAL junction data,increase the timeout value for acl-dist-delay in migrate.conf. For example,change the default setting from 20 to 60 seconds.

Restoring Access Manager dataBefore you begin restoring Access Manager data on the policy server, ensure thatthe following conditions are met:v Ensure that you restore user and group registry data before any other data

restoration. Restore ACL and POP data last. Otherwise, you might removesec_master’s permission to create objects in certain locations. In addition, ACLsare not restored correctly if the users and groups that they reference do not existin the restore target environment.

v Information is not appended to error files (specified with the –e option).Therefore, each error file name should be unique.

v On Windows systems only, ensure that you include the –r option with theoptions specified in the following procedure. The –r option specifies the full pathname of the ivmgrd.conf file for your current Version 3.9 installation. Forexample:-r "C:\Program Files\Tivoli\Policy Director\etc\ivmgrd.conf"

For reference information about this option and others, see Appendix D,“Installation commands” on page 219.

v Data is not written to the error file when restoring object and user information.You must specify the –a option to log errors in the log file. The default log file ismigration.log.

To restore Access Manager data, follow these steps:1. To restore user and group information, enter the following command:

migrate39 -t restore -s user -f user.xml -e obj_error.xml

where user.xml is the name of the file where user and group information isstored and migration.log is the name of the default log file that records failedoperations.

Notes:

v Make sure that you run the migrate39 command from the temporarydirectory on the policy server system.

v Currently, you must specify the –e option although errors are not logged tothis file.

2. To restore object spaces and the objects that they contain, enter the following:migrate39 -t restore -s obj -f object.xml -e obj_error.xml

where object.xml is the name of the file where all nondefault (user created)object information is stored and migration.log is the name of the default logfile that records failed operations.

3. To restore Global Sign-On (GSO) information (if installed), enter the following:migrate39 -t restore -s gso -f -e gso.xml

where gso.xml is the name of the file where the GSO information is stored andgso_error.xml is the name of the error file that record failed operations.


4. To restore local mode authorization API server information and configure eachserver with the parameters stored in the XML file during the backup operation,enter the following:migrate39 -t restore -s server -f server.xml -e server_error.xml

where server.xml is the name of the file where server information is stored andserver_error.xml is the name of the error file that records failed operations.

5. To restore actions, action groups, access control lists, and POP information,enter the following:migrate39 -t restore -s acls -f acls.xml -e acls_error.xml

where acls.xml is the name of the file where ACL and POP information isstored and acls_error.xml is the name of the error file that records failedoperations.

6. Evaluate the errors in the error files, fix the conditions that caused the errors,and then rerun the migrate39 command to retry the restoration with only theelements that caused the errors. Follow this routine until the restoration issuccessful and runs without errors.

Restoring a system to Version 3.7.1If you encounter a problem when migrating to Version 3.9 using the single-systemapproach, you might need to restore the system to the previous Version 3.7.1 level.To do so, follow these steps:

Note: If you encounter a problem during the backup of existing data, contactTivoli Support for assistance before continuing with the upgrade process.For more information, see “Contacting customer support” onpage xv“Contacting customer support” on page xii.

1. Ensure that all Access Manager applications and base services are stopped.2. Ensure that the Policy Director directory and the pdupgrade command are in

the temporary directory. If not, do one of the following to copy the pdupgradefile and any saved data to your temporary directory:v On UNIX systems, If a /var/PolDir directory does not exist, copy the

contents of /var/PolicyDirector/save37 to /var/PolDir. Then copy the file/opt/PolicyDirector/sbin/pdupgrade to /tmp.

v On Windows systems, copy the contents of install_path\save37 to%TMP%\PD37. Then copy the file install_path\bin\pdupgrade to %TMP%.

3. Remove Access Manager, Version 3.9, by doing one of the following:v On AIX systems, use smitty to remove the Access Manager packages from

the systemv On Solaris systems, enter the following commands:

rm -f /opt/PolicyDirector/.configure/*pkgrm package_namerm -fR /opt/PolicyDirectorrm -fR /var/PolicyDirector

The pkgrm command prompts if you want to continue removing thecomponent even though it is still configured. Enter yes to continue. If youhave dependencies installed, such as WebSEAL, you are prompted if youwant to uninstall the Policy Director base component even though there areapplications dependent on it. Enter yes to continue.

v On HP-UX systems, enter the following commands in this order:


rm -f /opt/PolicyDirector/.configure/*swremove -x enforce_dependencies=false package_namerm -fR /opt/PolicyDirectorrm -fR /var/PolicyDirector

v On Windows systems, follow these steps:a. Log in as a Windows user with administrator privilege.b. Select Start → Settings → Control Panel and then click the Add/Remove

Programs icon.c. Use the Add/Remove button to remove the Access Manager packages.

4. Install Tivoli SecureWay Policy Director, Version 3.7.1. For instructions, see theTivoli SecureWay Policy Director Base Installation Guide, Version 3.7.1 for yourparticular platform.

Note: On AIX systems only, you must issue the installp command with the –Foption. Or if using SMIT to install Version 3.7.1 packages, answer yeswhen prompted to overwrite same or newer versions and no whenprompted to automatically install requisite software.

5. Apply any Policy Director fix packs that were on the system prior to theupgrade to Version 3.9.

6. To restore your previous data, change to the temporary directory and enter thefollowing command:pdupgrade -restore

Restoring a system to Version 3.8If you encounter a problem when migrating to Version 3.9 using the single-systemapproach, you might need to restore the system to the previous Version 3.8 level.To do so, follow these steps:

Note: If you encounter a problem during the backup of existing data, contactTivoli Support for assistance before continuing with the upgrade process.For more information, see “Contacting customer support” onpage xv“Contacting customer support” on page xii.

1. Ensure that all Access Manager applications and base services are stopped.2. Remove Access Manager, Version 3.9, by doing one of the following:

v On AIX systems, use smitty to remove the Access Manager packages fromthe system

v On Solaris systems, enter the following commands:rm -f /opt/PolicyDirector/.configure/*pkgrm package_namerm -fR /opt/PolicyDirectorrm -fR /var/PolicyDirector

The pkgrm command prompts if you want to continue removing thecomponent even though it is still configured. Enter yes to continue. If youhave dependencies installed, such as WebSEAL, you are prompted if youwant to uninstall the Policy Director base component even though there areapplications dependent on it. Enter yes to continue.

v On HP-UX systems, enter the following commands in this order:rm -f /opt/PolicyDirector/.configure/*swremove -x enforce_dependencies=false package_namerm -fR /opt/PolicyDirectorrm -fR /var/PolicyDirector


v On Linux, enter the following command: rpm -Uvh package_name wherepackage_name is the Access Manager package name.

v On Windows systems, follow these steps:a. Log in as a Windows user with administrator privilege.b. Select Start → Settings → Control Panel and then click the Add/Remove

Programs icon.c. Use the Add/Remove button to remove the Access Manager packages.

3. Install Tivoli SecureWay Policy Director, Version 3.8. For instructions, see theTivoli Policy Director Base Installation Guide, Version 3.8 for your particularplatform.

Note: On AIX systems only, you must issue the installp command with the –Foption. Or if using SMIT to install Version 3.8 packages, answer yeswhen prompted to overwrite same or newer versions and no whenprompted to automatically install requisite software.

4. Apply any Policy Director fix packs that were on the system prior to theupgrade to Version 3.9.

5. To restore your previous data, change to the temporary directory and enter thefollowing command:pdbackup -action restore



Appendix B. OS/390 and z/OS LDAP configuration reference

This appendix includes samples for the following:v “Sample LDAP configuration”v “Sample DB2 database and tablespace script for SPUFI” on page 200v “Sample DB2 index script for SPUFI” on page 205v “Sample CLI bind batch job” on page 207v “Sample CLI initialization file” on page 209

Use these samples during the configuration process as described in “Configuringz/OS or OS/390 security servers” on page 49.

Sample LDAP configuration########################################################################## The values provided in this configuration file may reflect the## generic values given in the example DB2 setup files. Make sure you## use values appropriate for a production installation.########################################################################

########################################################################## Global definitions########################################################################port 3389adminDN "cn=root"adminPW password1########################################################################## tdbm database definitions########################################################################database tdbm GLDBTDBMservername LOC1dbuserid LDAPSRVdatabaseName LDAPR10dsnaoini SUADMIN.DSNAOINI.DB2INIsuffix "o=ibm,c=us"suffix "secAuthority=Default"AttrOverflowSize 80########################################################################## Native (SAF) Authentication for TDBM########################################################################useNativeAuth SELECTEDnativeAuthSubtree "o=ibm,c=us"nativeUpdateAllowed YES########################################################################## SSL definitions########################################################################securePort 6636security SSLsslKeyRingFile "/usr/lpp/ldap/etc/ldapserver.kdb"sslKeyRingFilePW password1sslCipherSpecs 15104########################################################################## Replica definitions########################################################################masterServer "ldap://jeff.endicott.ibm.com:3389"masterServerDN cn=mastermasterServerPW password1


Sample DB2 database and tablespace script for SPUFI

--*********************************************************************/--* This file contains sample code. IBM PROVIDES THIS CODE ON AN */--* ’AS IS’ BASIS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS */--* OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES */--* OF MERCHANT ABILITY OR FITNESS FOR A PARTICULAR PURPOSE. */--*********************************************************************/

-- Use the following statements to create your LDAP Server DB2 database-- and tablespaces in SPUFI. The database and tablespace names you-- create will be used to update the database section of the LDAP-- Server configuration file. You also need to make DB2 decisions,-- in terms of buffer pool size selection for tablespaces and column-- size selection, all of which will be directly related to the data that-- will be stored in the database. See the instructions below for-- more information.---- *************************-- Database Name Information-- *************************-- Change LDAPR10 to the name of the LDAP database name you want to create.-- Be sure this name is updated to match what is defined for databasename in-- the server configuration file.---- **************************-- DataBase Owner Information-- **************************-- Change the LDAPSRV to the MVS database owner id. This ID will be the-- highlevel qualifier for the tables---- **********************-- Tablespace Information-- **********************---- *********************************************************************-- NOTE: Refer to the DB2 manuals for a complete listing of valid buffer-- pool names.-- *********************************************************************---- Change the ENTRYTS to the LDAP entry tablespace name you want to create.---- Change the BP0 to the buffer pool name for the LDAP entry tablespace.-- The size of the buffer pool can be determined with the formula:---- result = 62 bytes + <dn column trunc size (from below)> +-- <maximum full size of a DN (from below)> +-- <size of entry data (which includes creator’s DN and modifiers DN)>---- There is also a concept of a "spill over" table, where if the entry-- data does not fit into the row size, it will be broken up in order-- to fit into a row. Entry data may be spread across multiple rows-- if needed. So in the above formula, the <size of entry data>-- does not need to be the maximum size of the data, maybe the median-- size of the data would be a better choice. See the long entry-- tablespace description below.---- The default suggested size is 4K.---- Change the LENTRYTS to the LDAP long entry tablespace name you want to-- create.---- Change the BP0 to the buffer pool name for the LDAP long entry-- tablespace. The long entry table space will hold "spill over" rows-- for entry data that does not fit into the entry table tablespace.-- To minimize the number of spill over rows, choose a large buffer


-- pool size.---- The default suggested size is 4K.---- Change the LATTRTS to the LDAP long attribute tablespace name you want to-- create.---- Change the BP0 to the buffer pool name for the LDAP long attribute-- tablespace. The long attribute table space will hold "spill over" rows-- for attribute data that does not fit into the entry table tablespace.-- To minimize the number of spill over rows, choose a large buffer-- pool size.---- The default suggested size is 4K.---- Change the MISCTS to the LDAP miscellaneous tablespace name you want to-- create.---- Change the DESCTS to the LDAP descendants tablespace name you want to-- create.---- Change the SEARCHTS to the LDAP search tablespace name you want to create.---- Change the BP0 to the buffer pool name for the LDAP search tablespace.-- The size of the buffer pool can be determined with the simple formula:---- result = 16 bytes + <search column trunc size (from below)> +-- <maximum size of attribute value you would like to search for>---- The result value is the maximum number of bytes a row in the search-- table containing an attribute value will occupy. Choose a buffer pool-- size which will accommodate this size.---- The default suggested size is 4K.---- Change the REPTS to the LDAP replica tablespace name you want to create.---- *********************************-- Column Size Selection Information-- *********************************-- All searchable attributes of a given entry will be stored in two forms.-- The first will be a truncated version, which will be used as part of-- a DB2 index. The second version will be the entire attribute value,-- potentially truncated by the buffer pool size you choose. The reason-- two versions are stored is so that LDAP/DB2 can use indexes to increase-- search performance. The reason we do not index the entire searchable-- attribute value is because the cost (in terms of DASD) associated with-- having indexes on a large column where there is a large amount of data.---- The choice of the search column trunc size should take into account system-- limits you may have (as described in the above), and should account-- for the typical size of the attribute values that are stored in-- LDAP. For example, if most of your data is only 20 bytes long,-- choosing 20 for this trunc size would be wise.---- Change 32 to the search column trunc size you determine best fits your-- attribute data.---- The default suggested size is 32.---- Another search performance enhancement is related to the DN attribute.-- The DN attribute value is stored separately from the entry data to allow-- a fast path lookup. It is also stored in two versions as well. The-- reasons are similar to those mentioned above for the attribute column.-- Since the DN data is stored in it’s own column, you need to define the-- maximum DN attribute value size here. You also need to choose a dn-- column trunc size that best fits your data.

Appendix B. OS/390 and z/OS LDAP configuration reference 201

---- Change 32 to the dn trunc size you determine best fits your dn data.---- The default suggested size is 32.---- Change 512 to the maximum size of a DN. This value includes the null-- terminator, so the actual maximum length of a DN will be one less than-- this value.---- The default suggested size is 512.------ *************************-- Storage Group Information-- *************************-- Change the SYSDEFLT to the storage group you want to contain the-- LDAP DB2 tablespaces. Use SYSDEFLT to choose the default storage group.-- NOTE: The values provided below for PRIQTY and SECQTY probably need to be-- modified depending on the projected size of the Directory information to-- be stored.--

-- ***************************************************************************-- Use the following statements if you need to delete your LDAP Server DB2-- database and tablespaces in SPUFI. You need to remove the ’--’-- from each line before you can run these statements.-- Change the ENTRYTS to the LDAP entry tablespace name you want to delete.-- Change the LENTRYTS to the LDAP long entry tablespace name you want to-- delete.-- Change the LATTRTS to the LDAP long attr tablespace name you want to-- delete.-- Change the MISCTS to the LDAP miscellaneous tablespace name you want to-- delete.-- Change the SEARCHTS to the LDAP search tablespace name you want to delete.-- Change the REPTS to the LDAP replica tablespace name you want to delete.-- Change the DESCTS to the LDAP descendants tablespace name you want to-- delete.-- Change the LDAPR10 to the LDAP database name you want to delete.-- ***************************************************************************

--DROP TABLESPACE LDAPR10.ENTRYTS;--DROP TABLESPACE LDAPR10.LENTRYTS;--DROP TABLESPACE LDAPR10.LATTRTS;--DROP TABLESPACE LDAPR10.MISCTS;--DROP TABLESPACE LDAPR10.SEARCHTS;--DROP TABLESPACE LDAPR10.REPTS;--DROP TABLESPACE LDAPR10.DESCTS;--DROP DATABASE LDAPR10;--COMMIT;

-- ************************-- Create the LDAP database-- ************************CREATE DATABASE LDAPR10 STOGROUP SYSDEFLT;

-- ********************************-- Create the LDAP entry tablespace-- ********************************CREATE TABLESPACE ENTRYTS IN LDAPR10

USING STOGROUP SYSDEFLTBUFFERPOOL BP0;

-- *************************************-- Create the LDAP long entry tablespace-- *************************************CREATE TABLESPACE LENTRYTS IN LDAPR10

USING STOGROUP SYSDEFLT


BUFFERPOOL BP0;

-- ************************************-- Create the LDAP long attr tablespace-- ************************************CREATE TABLESPACE LATTRTS IN LDAPR10


-- *****************************-- Create the LDAP 4K tablespace-- *****************************CREATE TABLESPACE MISCTS IN LDAPR10

SEGSIZE 4USING STOGROUP SYSDEFLTBUFFERPOOL BP0;

-- *********************************-- Create the LDAP search tablespace-- *********************************CREATE TABLESPACE SEARCHTS IN LDAPR10


-- *********************************-- Create the LDAP replica tablespace-- *********************************CREATE TABLESPACE REPTS IN LDAPR10


-- *****************************-- Create the LDAP descendants tablespace-- *****************************CREATE TABLESPACE DESCTS IN LDAPR10


-- *********************-- Create the DB2 tables-- *********************

-- **************************-- Create the DIR_ENTRY table-- **************************CREATE TABLE LDAPSRV.DIR_ENTRY (

EID DECIMAL(15 , 0) NOT NULL,PEID DECIMAL(15 , 0),ENTRY_SIZE INTEGER,LEVEL INTEGER,ACLSRC DECIMAL(15 , 0),ACLPROP CHAR(1),OWNSRC DECIMAL(15 , 0),OWNPROP CHAR(1),CREATE_TIMESTAMP TIMESTAMP,MODIFY_TIMESTAMP TIMESTAMP,DN_TRUNC CHAR(32) FOR BIT DATA,DN VARCHAR(512) FOR BIT DATA,ENTRYDATA LONG VARCHAR FOR BIT DATA,PRIMARY KEY( EID ) )

IN LDAPR10.ENTRYTS;

-- ******************************-- Create the DIR_LONGENTRY table-- ******************************CREATE TABLE LDAPSRV.DIR_LONGENTRY (

EID DECIMAL(15 , 0) NOT NULL,


SEQ INTEGER NOT NULL,ENTRYDATA LONG VARCHAR FOR BIT DATA,PRIMARY KEY( EID, SEQ ) )

IN LDAPR10.LENTRYTS;

-- *****************************-- Create the DIR_LONGATTR table-- *****************************CREATE TABLE LDAPSRV.DIR_LONGATTR (

EID DECIMAL(15 , 0) NOT NULL,ATTR_ID INTEGER NOT NULL,VALUENUM INTEGER NOT NULL,SEQ INTEGER NOT NULL,ATTRDATA LONG VARCHAR FOR BIT DATA,PRIMARY KEY( EID, ATTR_ID, VALUENUM, SEQ ) )

IN LDAPR10.LATTRTS;

-- *****************************-- Create the DIR_MISC table-- *****************************CREATE TABLE LDAPSRV.DIR_MISC (

NEXT_EID DECIMAL(15 , 0),NEXT_ATTR_ID INTEGER,DB_VERSION CHAR(10),DB_CREATE_VERSION CHAR(10) )

IN LDAPR10.MISCTS;

-- **************************-- Create the DIR_CACHE table-- **************************CREATE TABLE LDAPSRV.DIR_CACHE (

CACHE_NAME CHAR(25) NOT NULL,MODIFY_TIMESTAMP TIMESTAMP NOT NULL,PRIMARY KEY( CACHE_NAME, MODIFY_TIMESTAMP ) )

IN LDAPR10.MISCTS;

-- ***************************-- Create the DIR_ATTRID table-- ***************************CREATE TABLE LDAPSRV.DIR_ATTRID (

ATTR_ID INTEGER,ATTR_NOID VARCHAR(200) NOT NULL,PRIMARY KEY( ATTR_NOID ) )

IN LDAPR10.MISCTS;

-- *************************-- Create the DIR_DESC table-- *************************CREATE TABLE LDAPSRV.DIR_DESC (

DEID DECIMAL(15 , 0) NOT NULL,AEID DECIMAL(15 , 0) NOT NULL,PRIMARY KEY( DEID, AEID ) )

IN LDAPR10.DESCTS;

-- ***************************-- Create the DIR_SEARCH table-- ***************************CREATE TABLE LDAPSRV.DIR_SEARCH (

EID DECIMAL(15 , 0) NOT NULL,ATTR_ID INTEGER NOT NULL,VALUE CHAR(32) FOR BIT DATA,LVALUE LONG VARCHAR FOR BIT DATA )

IN LDAPR10.SEARCHTS;

-- *****************************-- Create the DIR_REGISTER table-- *****************************


CREATE TABLE LDAPSRV.DIR_REGISTER (ID INTEGER NOT NULL,SRV VARCHAR(125) NOT NULL,PRIMARY KEY( ID, SRV ) )

IN LDAPR10.MISCTS;

-- *****************************-- Create the DIR_PROGRESS table-- *****************************CREATE TABLE LDAPSRV.DIR_PROGRESS (

ID INTEGER NOT NULL,PRG VARCHAR(125) NOT NULL,SRV VARCHAR(125) NOT NULL,PRIMARY KEY( ID, PRG, SRV ) )

IN LDAPR10.MISCTS;

-- ***************************-- Create the DIR_CHANGE table-- ***************************CREATE TABLE LDAPSRV.DIR_CHANGE (

ID INTEGER NOT NULL,TYPE INTEGER NOT NULL,LONGENTRY_SIZE INTEGER,DIN VARCHAR(512) NOT NULL,LDIF LONG VARCHAR NOT NULL,PRIMARY KEY( ID ) )

IN LDAPR10.REPTS;

-- *******************************-- Create the DIR_LONGCHANGE table-- *******************************CREATE TABLE LDAPSRV.DIR_LONGCHANGE (

ID INTEGER NOT NULL,SEQ INTEGER NOT NULL,LDIF LONG VARCHAR,PRIMARY KEY( ID, SEQ ) )

IN LDAPR10.REPTS;

-- ***********************************-- Commit all the above SQL statements-- ***********************************COMMIT;

Sample DB2 index script for SPUFI

--*********************************************************************/--* This file contains sample code. IBM PROVIDES THIS CODE ON AN */--* ’AS IS’ BASIS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS */--* OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES */--* OF MERCHANT ABILITY OR FITNESS FOR A PARTICULAR PURPOSE. */--*********************************************************************/---- Use the following statements to create your LDAP Server DB2-- indexes in SPUFI. See the instructions below for more information.---- **************************-- DataBase Owner Information-- **************************-- Change the LDAPSRV to the MVS database owner id. This ID will be the-- highlevel qualifier for the tables. This value should correspond-- with the value chosen in the LDAP Server DB2 database and tablespace-- SPUFI script.---- *************************-- Storage Group Information-- *************************


-- Change the SYSDEFLT to the storage group you want to contain the-- LDAP DB2 indexes. Use SYSDEFLT to choose the default storage group.-- NOTE: The values provided below for PRIQTY and SECQTY probably need-- to be modified depending on the projected size of the Directory-- information to be stored.---- *************************-- Miscellaneous Information-- *************************-- All indexes have been defined DEFER YES, which means they need to be-- recovered at some point. It is suggested to do the recovery after-- the database has been populated for databases with large amounts of-- data. Use of this option is strictly optional though.---- To NOT use the DEFER YES option, simply remove DEFER YES globally.--

-- ****************************-- Create the DIR_ENTRY indexes-- ****************************CREATE UNIQUE INDEX LDAPSRV.DIR_ENTRYX0 ON LDAPSRV.DIR_ENTRY( EID )

USING STOGROUP SYSDEFLTDEFER YES;

CREATE INDEX LDAPSRV.DIR_ENTRYX1 ON LDAPSRV.DIR_ENTRY( PEID, EID )USING STOGROUP SYSDEFLTDEFER YES;

CREATE INDEX LDAPSRV.DIR_ENTRYX2 ON LDAPSRV.DIR_ENTRY( EID, DN_TRUNC )USING STOGROUP SYSDEFLTDEFER YES;

CREATE INDEX LDAPSRV.DIR_ENTRYX3 ON LDAPSRV.DIR_ENTRY( DN_TRUNC, EID )USING STOGROUP SYSDEFLTDEFER YES;

-- ********************************-- Create the DIR_LONGENTRY indexes-- ********************************CREATE UNIQUE INDEX LDAPSRV.DIR_LONGENTRYX1

ON LDAPSRV.DIR_LONGENTRY( EID, SEQ )USING STOGROUP SYSDEFLTDEFER YES;

-- *******************************-- Create the DIR_LONGATTR indexes-- *******************************CREATE UNIQUE INDEX LDAPSRV.DIR_LONGATTRX1

ON LDAPSRV.DIR_LONGATTR( EID, ATTR_ID, VALUENUM, SEQ )USING STOGROUP SYSDEFLTDEFER YES;

-- ****************************-- Create the DIR_CACHE indexes-- ****************************CREATE UNIQUE INDEX LDAPSRV.DIR_CACHEX1

ON LDAPSRV.DIR_CACHE( CACHE_NAME, MODIFY_TIMESTAMP )USING STOGROUP SYSDEFLTDEFER YES;

-- *****************************-- Create the DIR_ATTRID indexes-- *****************************CREATE UNIQUE INDEX LDAPSRV.DIR_ATTRIDX1

ON LDAPSRV.DIR_ATTRID( ATTR_NOID )USING STOGROUP SYSDEFLTDEFER YES;

-- ***************************


-- Create the DIR_DESC indexes-- ***************************CREATE UNIQUE INDEX LDAPSRV.DIR_DESCX1

ON LDAPSRV.DIR_DESC( DEID, AEID )USING STOGROUP SYSDEFLTDEFER YES;

-- *****************************-- Create the DIR_SEARCH indexes-- *****************************CREATE INDEX LDAPSRV.DIR_SEARCHX1

ON LDAPSRV.DIR_SEARCH( ATTR_ID, VALUE, EID )USING STOGROUP SYSDEFLTDEFER YES;

CREATE INDEX LDAPSRV.DIR_SEARCHX2ON LDAPSRV.DIR_SEARCH( EID, ATTR_ID )USING STOGROUP SYSDEFLT CLUSTERDEFER YES;

-- *******************************-- Create the DIR_REGISTER indexes-- *******************************CREATE UNIQUE INDEX LDAPSRV.DIR_REGISTERX1

ON LDAPSRV.DIR_REGISTER( ID, SRV )USING STOGROUP SYSDEFLTDEFER YES;

-- *******************************-- Create the DIR_PROGRESS indexes-- *******************************CREATE UNIQUE INDEX LDAPSRV.DIR_PROGRESSX1

ON LDAPSRV.DIR_PROGRESS( ID, PRG, SRV )USING STOGROUP SYSDEFLTDEFER YES;

-- *****************************-- Create the DIR_CHANGE indexes-- *****************************CREATE UNIQUE INDEX LDAPSRV.DIR_CHANGEX1 ON LDAPSRV.DIR_CHANGE( ID )

USING STOGROUP SYSDEFLTDEFER YES;

-- *********************************-- Create the DIR_LONGCHANGE indexes-- *********************************CREATE UNIQUE INDEX LDAPSRV.DIR_LONGCHANGEX1

ON LDAPSRV.DIR_LONGCHANGE( ID, SEQ )USING STOGROUP SYSDEFLTDEFER YES;

-- ***********************************-- Commit all the above SQL statements-- ***********************************COMMIT;

Sample CLI bind batch job

//DSNTIJCL JOB (DB2),// ’PGMRNAME’,// CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),// REGION=4M//*//*********************************************************************///* This file contains sample code. IBM PROVIDES THIS CODE ON AN *///* ’AS IS’ BASIS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS */


//* OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES *///* OF MERCHANT ABILITY OR FITNESS FOR A PARTICULAR PURPOSE. *///*********************************************************************///*********************************************************************///* JOB NAME = DSNTIJCL *///* DESCRIPTIVE NAME = INSTALLATION JOB STREAM *///* LICENSED MATERIALS - PROPERTY OF IBM *///* 5655-DB2 *///* (C) COPYRIGHT 1982, 1997 IBM CORP. ALL RIGHTS RESERVED. *///* STATUS = VERSION 5 *///* FUNCTION = SAMPLE CLI BIND *///* PSEUDOCODE = BINDCLI STEP BIND CLI DEFAULT PACKAGES AND PLAN *///* DEPENDENCIES = CLI MUST BE INSTALLED *///* MEMBER DSNCLIQR CAN ONLY BE BOUND SUCCESSFULLY TO DRDA SERVERS *///* THAT SUPPORT QUERY RESULT SET SQL (I.E. DESCRIBE PROCEDURE). *///* CURRENTLY THAT IS DB2 FOR OS/390 V5. *///* *///* NOTES = *///* BEFORE RUNNING THIS JOB: *///* - CHANGE ALL OCCURRENCES OF DSN5 TO THE PREFIX OF YOUR DB2 V5.1 *///* SDSNLOAD AND SDSNDBRM DATA SETS *///* - CHANGE THE SYSTEM(DSN5) STATEMENT TO MATCH YOUR DB2 V5.1 SSID *///* *///* CLI CAN BE BOUND TO REMOTE SERVERS BY INCLUDING THE LOCATION NAME.*///* *///* FOR REMOTE SERVERS OTHER THAN DB2 FOR OS/390, ALSO ADD THE *///* APPROPRIATE BIND PACKAGE MEMBER STATEMENTS, LISTED BELOW, *///* BASED ON THE SERVER TYPE: *///* BIND PACKAGE (<COMMON SERVER V1 LOCATION NAME>.DSNAOCLI) - *///* MEMBER(DSNCLIV1) *///* BIND PACKAGE (<COMMON SERVER V2 LOCATION NAME>.DSNAOCLI) - *///* MEMBER(DSNCLIV2) *///* BIND PACKAGE (<AS400 LOCATION NAME>.DSNAOCLI) - *///* MEMBER(DSNCLIAS) *///* BIND PACKAGE (<SQLDS LOCATION NAME>.DSNAOCLI) - *///* MEMBER(DSNCLIVM) *///* ALSO INCLUDE ANY ADDED PACKAGE NAMES TO THE PKLIST KEYWORD OF *///* BIND PLAN STATEMENT FOLLOWING THE BIND PACKAGE STATEMENTS. *///* *///*********************************************************************///JOBLIB DD DISP=SHR,// DSN=DSN510.SDSNLOAD//BINDCLI EXEC PGM=IKJEFT01,DYNAMNBR=20//DBRMLIB DD DISP=SHR,// DSN=DSN510.SDSNDBRM//SYSTSPRT DD SYSOUT=*//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD *DSN SYSTEM(DSN5)

BIND PACKAGE (DSNAOCLI) MEMBER(DSNCLICS) ISOLATION(CS)BIND PACKAGE (DSNAOCLI) MEMBER(DSNCLINC) ISOLATION(NC)BIND PACKAGE (DSNAOCLI) MEMBER(DSNCLIRR) ISOLATION(RR)BIND PACKAGE (DSNAOCLI) MEMBER(DSNCLIRS) ISOLATION(RS)BIND PACKAGE (DSNAOCLI) MEMBER(DSNCLIUR) ISOLATION(UR)BIND PACKAGE (DSNAOCLI) MEMBER(DSNCLIC1)BIND PACKAGE (DSNAOCLI) MEMBER(DSNCLIC2)BIND PACKAGE (DSNAOCLI) MEMBER(DSNCLIF4)BIND PACKAGE (DSNAOCLI) MEMBER(DSNCLIMS)BIND PACKAGE (DSNAOCLI) MEMBER(DSNCLIQR)

BIND PLAN(DSNACLI) -PKLIST(DSNAOCLI.DSNCLICS -

DSNAOCLI.DSNCLINC -DSNAOCLI.DSNCLIRR -DSNAOCLI.DSNCLIRS -


DSNAOCLI.DSNCLIUR -DSNAOCLI.DSNCLIC1 -DSNAOCLI.DSNCLIC2 -DSNAOCLI.DSNCLIF4 -DSNAOCLI.DSNCLIMS -DSNAOCLI.DSNCLIQR )

END/*

ECLI Initialization File; This is a comment line...

;/*********************************************************************/;/* This file contains sample code. IBM PROVIDES THIS CODE ON AN */;/* ’AS IS’ BASIS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS */;/* OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES */;/* OF MERCHANT ABILITY OR FITNESS FOR A PARTICULAR PURPOSE. */;/*********************************************************************/

; Example COMMON stanza;; The MVSDEFAULTSSID option indicates what DB2; subsystem should be used for interacting with; DB2 tables. This value is installation dependent.; It is assumed to be DSN5 for this example.[COMMON]MVSDEFAULTSSID=DSN5

; Example SUBSYSTEM stanza for DSN5 subsystem;; NOTE: the PLANNAME option below must match the; plan name that was specified when running the; DSNTIJCL batch job to create the plan. It is; assumed to be DSNACLI for this example.[DSN5];MVSATTACHTYPE=CAFMVSATTACHTYPE=RRSAFPLANNAME=DSNACLI

; Example DATA SOURCE stanza;; The DATA SOURCE name is installation dependent.; It is assumed to be LOC1 for this example.[LOC1]AUTOCOMMIT=0CONNECTTYPE=1

Sample CLI initialization file; This is a comment line...;/*********************************************************************/;/* This file contains sample code. IBM PROVIDES THIS CODE ON AN */;/* ’AS IS’ BASIS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS */;/* OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES */;/* OF MERCHANT ABILITY OR FITNESS FOR A PARTICULAR PURPOSE. */;/*********************************************************************/; Example COMMON stanza;; The MVSDEFAULTSSID option indicates what DB2; subsystem should be used for interacting with; DB2 tables. This value is installation dependent.; It is assumed to be DSN5 for this example.[COMMON]MVSDEFAULTSSID=DSN5; Example SUBSYSTEM stanza for DSN5 subsystem;


; NOTE: the PLANNAME option below must match the; plan name that was specified when running the; DSNTIJCL batch job to create the plan. It is; assumed to be DSNACLI for this example.[DSN5];MVSATTACHTYPE=CAFMVSATTACHTYPE=RRSAFPLANNAME=DSNACLI; Example DATA SOURCE stanza;; The DATA SOURCE name is installation dependent.; It is assumed to be LOC1 for this example.[LOC1]AUTOCOMMIT=0CONNECTTYPE=1


Appendix C. Easy installation scenarios

This appendix provides the following scenarios using easy installation scripts:v “Creating a secure domain”v “Installing Web portal manager” on page 215

For more information about using easy installation to install IBM Tivoli AccessManager (Access Manager) components, see the chapter for your particularplatform.

Creating a secure domainThe following scenario shows you how to set up LDAP server and policy serversystems; thereby, creating a secure domain. For descriptions of the configurationoptions used in this scenario, refer to the easy installation configuration options inthe ″Installing Access Manager, Version 3.9″ chapter for your particular platform.

Note that for the purpose of this scenario, the IBM SecureWay Directory server isinstalled as your LDAP server and Secure Sockets Layer (SSL) communication isenabled between the LDAP server and IBM SecureWay Directory clients.1. To create a secure domain using easy installation, you must first install a

supported LDAP server. For example, to install the IBM SecureWay Directoryserver and prerequisite software, run the ezinstall_ldap_server script. Awindow similar to the following is displayed, listing required products:

2. To start the installation process, press Enter and supply configurationinformation when prompted. To modify an option, enter its associated number.For example, to change the HTTP port in the following window, press 3 and


then enter the port value that you want to use. To begin configuration, press y.

3. As products are installed, you are prompted for configuration information. Forexample, IBM SecureWay Directory server configuration options are as follows:

Note that descriptions of these configuration options are provided in the″Installing Access Manager, Version 3.9″ chapter for your particular platform.

4. After you have successfully completed installing the IBM SecureWay Directoryserver, you must set up a policy server system. To do this, run the


ezinstall_pdmgr file. A window similar to the following is displayed:

Note that if you plan to install the policy server on the same system as theLDAP server, the ezinstall_pdmgr script detects that the IBM Global SecurityToolkit and the IBM SecureWay Directory client products are already installedand configured.

5. Next, enter configuration options for the Access Manager runtime environmentpackage and then press y to begin configuration.

6. Continue to supply configuration information when prompted. For thepurposes of this scenario, SSL is enabled and Access Manager client systems areable to download the CA certificate file. For example, options appear similar to

Appendix C. Easy installation scenarios 213

the following:

7. When policy server installation and configuration has completed, you arenotified as follows:

8. Optionally, you can set up additional systems in your secure domain. Forexample, you can do the following:v Run the ezinstall_pdrte file to install one or more runtime client systems

(without the policy server).v Run the ezinstall_pdauthADK script to install a development system with

the application development kit (ADK).v Run the ezinstall_pdacld script to set up an authorization server system.v Run the ezinstall_pdwpm script to install the Web portal manager interface

with PTF.


Installing Web portal managerThe following scenario shows you how to install Web portal manager and thefollowing prerequisite components on a Windows system:v IBM Global Security Toolkit (GSKit)v IBM SecureWay Directory clientv Access Manager Runtimev IBM HTTP Serverv IBM WebSphere Application Server, Advanced Single Server with associated

Program Temporary Fix (PTF)

Notes:v This Windows scenario is similar to using easy installation on supported AIX

and Solaris platforms. For operating system requirements and supported Webbrowsers, see “Access Manager Web portal manager” on page 9.

v If you set up Domino or Active Directory as your user registry, you cannot useeasy installation. The easy installation option is currently available only whenusing an LDAP-based user registry.

To install Web Portal Manager on a Windows system, follow these steps:1. Run ezinstall_pdwpm.bat, located in the root directory on the IBM Tivoli

Access Manager Web Portal Manager for Windows CD.2. If you previously ran an easy installation script on this system, you are

prompted to use the stored response file. Do one of the following:v Enter y if you want to install Web portal manager using the configuration

information stored in the response file. Depending on the contents of yourresponse file, you might see one or more of the following windows. Awindow appears only if an entry for it is missing in the response file. Formore information about response files, see the response file section in thechapter for your particular platform.

v Enter n to continue to the step 33. A window displays the components that are already installed on your system.

Press Enter to continue.

Note: If you previously installed the Access Manager runtime component onthis system, the Status column indicates that the IBM Global SecurityToolkit, the IBM SecureWay Directory Client and the Access ManagerRuntime components are already installed. In this case, skip to step 10on page 217


on page 217.

4. To install the IBM Global Security Toolkit, press y. GSKit is automaticallyinstalled and configured.

5. From the IBM HTTP Server Configuration Options window, type thepassword associated with the LDAP administrator ID and press Enter. Thentype y and press Enter to install the IBM HTTP Server using default settings.

6. From the IBM SecureWay Directory Client window, type y and press Enter toinstall the IBM SecureWay Directory client in the specified default location.

7. From the IBM Tivoli Access Manager Runtime Configuration Options window,do the following:


a. Type the fully qualified host name of the LDAP server and then pressEnter.

b. Type the distinguished name of where in the LDAP server directoryinformation tree (DIT) that the Global Sign-On (GSO) database is located.For more information about the GSO suffix, see “LDAP serverconfiguration overview” on page 33.

c. Type the fully qualified host name of the policy server and press Enter.

You are prompted for additional configuration options for the runtimeenvironment. For a list and descriptions of these options, see the AccessManager runtime section of the ″Installing Access Manager, Version 3.9″chapter for your particular platform.

8. When you have completed and reviewed your options, type Y and pressEnter to install and configure the runtime environment.

9. The following prompt is displayed:If you have enabled PDMgr to allow the download of the certificate files,leave this option blank. Otherwise, specify the pdcacert.b64 filecreated by the PDMgr configuration. Enter the path to the Policy Directorcertificate file:

If you have not enabled the policy server to allow the certificate files to bedownloaded, enter the fully-qualified path to the desired certification file andpress Enter. Otherwise, leave this option blank and press Enter as specified.

10. From the IBM WebSphere Configuration Options window, enter the passwordfor the administration ID displayed and press Enter. Press y to install theWebSphere server with associated PTF.


11. The installation and configuration process begins. When all components areinstalled, press Enter to restart your system.The installed components are then configured, and the Web portal managerinterface is installed. For more information about Web portal manager and thetasks you can perform, see the IBM Tivoli Access Manager Base Administrator’sGuide.


Appendix D. Installation commands

This appendix lists, in alphabetical order, the commands related to installing,configuring, and migrating to IBM Tivoli Access Manager (Access Manager),Version 3.9.

Command syntaxThe commands in this appendix use the following special characters to definecommand syntax:

[ ] Identifies elements that are optional. Those not enclosed in brackets arerequired.

... Indicates that you can specify multiple values for the previous element.Separate multiple values by a space, unless otherwise directed by acommand’s information.

If the ellipsis for an element follows a closing bracket, use the syntaxwithin the brackets to specify multiple values. For example, to specify twoadministrators for the option [–a admin]..., use –a admin1 –a admin2.

If the ellipsis for an element is within the brackets, use the syntax of thelast element to specify multiple values. For example, to specify two hostsfor the option [–h host...], use –h host1 host2.

| Indicates mutually exclusive information. You can use the element oneither the left or right of the vertical bar.

{ } Delimits a set of mutually exclusive elements when one of them isrequired. If the elements are optional, they are enclosed in brackets ([ ]).

In addition to the special characters, the typeface conventions described in“Typeface conventions” on page xvi are used.


migrate37

PurposeBacks up registry data during the upgrade process. For instructions on how to usethis command, see “Backing up Access Manager data” on page 192.

Syntaxmigrate37 [–a {filename.log}] [–d {dce | ldap}] –f {filename.xml} [–l pathfilename.conf] –r {path} –s suboption –t backup [–v]

Options–a {filename.log}

Specifies the name of the log file that records all successful andfailed operations. The default log file is named migration.log. Fordescriptions of LDAP error codes listed in these log files, see theTivoli Customer Support Web site at:


–d {dce | ldap}Specifies the database in which the user information is currentlystored. Options include either Distributed Computing Environment(dce) or Lightweight Directory Access Protocol (ldap). The defaultvalue is dce.

–f filename.xml Specifies the name of the XML-formatted intermediate output file.This option is required.

–l path filename.confSpecifies the path and file name of the migration configuration file.Use this option only if you change the name of the defaultconfiguration file, migrate.conf, or place it in a directory other thanthe temporary directory on your system.

–r {path} For Windows only, specifies the full path name of the ivmgrd.confconfiguration file. This option is required. The path name must beenclosed by double quotation marks.

Note that the path name of the ivmgrd.conf file changed inVersion 3.8. Therefore, if backing up data on a Version 3.7.1 system,specify the path where the file resides in your existing Version 3.7.1installation. For example, the default path of the file for Version3.7.1 is as follows:-r "C:\Program Files\Tivoli\Policy Director\ivmgrd\lib\ivmgrd.conf"

where C:\Program Files\Tivoli\Policy Director\ivmgrd\lib isthe path specified during Access Manager, Version 3.7.1installation.

When restoring data on a Version 3.8 system, specify the defaultpath for Version 3.8 as follows:-r "C:\Program Files\Tivoli\Policy Director\etc\ivmgrd.conf"

–s {suboption} Specifies the type of the migration. This option is required. Chooseone of the following suboptions:


acls Indicates to back up protected object policy (POP), actions,action groups, and access control lists (ACLs) that areconfigured.

The data for each ACL includes the name, description, listof entries, and the attachment points in the object space.Data also is stored for each ACL entry, including the set ofpermissions and the user or group that the entry appliesto.

gso Specifies to back up Global Sign-on user information.

object Indicates to back up object spaces and the objectscontained within.

Note: When specifying this suboption, errors are logged inthe migration.log file only. Error output is notstored in the error XML file that you specified withthe –e option.

server Indicates to back up information about the Access Managerservers that are currently configured in your securedomain. For example, this option stores information aboutthe policy server, authorization server, WebSEAL, and soon. Stored information includes the name of the server, thename of the host on which it is running, the port that theserver is listening on, and the mode that the server isoperating in (either local or remote).

user Indicates to back up user and group data from a DCEregistry only.

Notes:

v Restore user and group registry data before any otherdata restoration.

v You do not have to back up users if you are migratingfrom Access Manager, Version 3.7.1 with LDAP registryand plan to use the same server.

v When specifying this suboption, errors are logged in themigration.log file only. Error output is not stored in anerror XML file that you specified with the –e option.

Note: You can shorten an option name, but the abbreviation mustbe unambiguous. For example, you can type obj for object.

–t backup Specifies to perform a backup operation. This option is required.

–v Prints the build version of the migrate37 command and the datethat it was built.

Examples1. The following example backs up all ACL and POP information on a Windows

system. The information is stored in the acls.xml file. Error information isstored in the migration.log file.migrate37 -t backup -s acls -f aclspop.xml -rC:\Program Files\Tivoli\Policy Director\ivmgrd\lib\ivmgrd.conf -d dce

Appendix D. Installation commands 221

AvailabilityThe migrate37 command is located in the following directories on the IBM TivoliAccess Manager Base CD for your particular platform. You must copy these files tothe temporary directory on your system before starting the upgrade process.v For AIX systems:


v For HP-UX systems:cd_path/hp/migrate

v For Solaris systems:cd_path/solaris/migrate

v For Windows systems:cd_path\windows\migrate


migrate39

PurposeRestores registry data during the upgrade process.

Syntaxmigrate39 [–a {filename.log}] –e filename.xml –f {filename.xml} [–l path filename.conf]–r {path} –s suboption –t restore [–v]

Options–a {filename}

Specifies the name of the log file that records all successful and failedoperations. The default log file is named migration.log. For descriptions ofLDAP error codes listed in these log files, see the Tivoli Customer SupportWeb site at:


–e filename.xmlSpecifies the name of a user-defined error file. Access Manager requiresthis option when restoring ACLs and server data only. This XML-formattedfile captures a record of only the ACL, WebSEAL junction, user and groupelements that fail to restore, as well as any elements that the failed elementdepends on.

You must edit this error file, fix the conditions that caused the erros, anduse the file as input to this command. For example, suppose that youattempt to restore ACL information and some of the operations failed (asspecified in your error file). You must correct the errors in the error fileand use it as input to the –s acls option when running migrate39. Theerror file becomes the input file on each iterative round of error validationuntil the restoration is successful and runs without errors.

Notes:v When restoring object and user information, error information is logged

in the log file, not the error file. The default log file is migration.log.However, currently you must still specify the –e option for therestoration process to work correctly.

v The error file name must be unique for each restore operation that youperform. If you use the same error file name, previous error data isdeleted, not appended to the file.

–f filename.xmlSpecifies the name of the XML-formatted intermediate output file.Thisoption is required.

–l path filename.confSpecifies the path and file name of the migration configuration file. Usethis option only if you change the name of the default configuration file,migrate.conf, or place it in a directory other than the temporary directoryon your system.

–r {path}For Windows only, specifies the full path name of the ivmgrd.confconfiguration file for your current Access Manager installation. The pathname must be enclosed by double quotation marks. This option is required


on Windows systems. Note that the path name of the ivmgrd.conf filechanged in Version 3.8. Therefore, if backing up data on a Version 3.7.1system, specify the following:–r "C:\Program Files\Tivoli\Policy Director\ivmgrd\lib\ivmgrd.conf"

When restoring data on a Version 3.8 system, specify the default path forVersion 3.8 as follows:–r "C:\Program Files\Tivoli\Policy Director\etc\ivmgrd.conf"

–s {suboption}Specifies the type of the restoration. This option is required. Choose one ofthe following suboptions:

acls Indicates to restore protected object policy (POP), actions, actiongroups, and access control lists (ACLs) that are configured.

Note: ACL and POP data must be restored last. Otherwise, youmight remove sec_master’s permission to create objects incertain locations. In addition, ACLs are not be restoredcorrectly if the users and groups that they reference do notexist in the restore target environment.

gso Indicates to restore Global Sign-on information.

objectIndicates to restore object spaces and the objects contained within.

server Indicates to restore information about the Access Manager serversthat are currently configured in your secure domain. For example,this option restores information about the policy server,authorization server, WebSEAL, and so on.

user Indicates to restore user and group data.

Note: You can shorten an option name, but the abbreviation must beunambiguous. For example, you can type obj for object.

–t restoreSpecifies to perform a restore operation. For DCE, you can restore otherDCE components, other than DCE user and group information, such asACL and WebSEAL junction information. DCE user and group informationcan only be restored to the LDAP DCE registry because of a DCEpassword limitation. This option is required.

–v Prints the build version of the migrate39 command and date it was built.

Examples1. The following example restores ACL and POP information stored in the

aclspop.xml file on a Windows system:migrate39 -t restore -s acls -f aclspop.xml-r C:\Program Files\Tivoli\Policy Director\etc\ivmgrd.conf -e acls_error.xml

After you restore information, edit the acls_error.xml error file to evaluate andfix any elements that failed to restore. For example, suppose that your error filecontained the following information:<IVMIG REGISTRY="LDAP" DATE="Jul 30 2001"><POPLIST><POPDATA><POPNAME>testpop</POPNAME>


<POPDESCRIPTION></POPDESCRIPTION><AUDITLEVEL>0</AUDITLEVEL><POPQOP>0</POPQOP><DAYS>127</DAYS><TODSTART>0</TODSTART><TODEND>0</TODEND><TODREFERENCE>0</TODREFERENCE><ANYOTHERNW>0</ANYOTHERNW><IPAUTHLIST></IPAUTHLIST><POPATTACHED>/foo</POPATTACHED></POPDATA></POPLIST></IVMIG>

In the previous example, the migrate39 command was unable to restoretestpop because another POP with the same name existed. You might replacethe <POPNAME> entry with a new name, such as newpop, as shown in thefollowing example:<IVMIG REGISTRY="LDAP" DATE="Jul 30 2001"><POPLIST><POPDATA><POPNAME>newpop</POPNAME><POPDESCRIPTION></POPDESCRIPTION><AUDITLEVEL>0</AUDITLEVEL><POPQOP>0</POPQOP><DAYS>127</DAYS><TODSTART>0</TODSTART><TODEND>0</TODEND><TODREFERENCE>0</TODREFERENCE><ANYOTHERNW>0</ANYOTHERNW><IPAUTHLIST></IPAUTHLIST><POPATTACHED>/blah</POPATTACHED></POPDATA></POPLIST></IVMIG>

In turn, use the error file as input to the migrate39 command and choose adifferent name for your new error file, for example, pass2_error.xml as shown:migrate39 -t restore -s acls -f aclspop_error.xml-r C:\Program Files\Tivoli\Policy Director\etc\ivmgrd.conf -e pass2_error.xml

AvailabilityThe migrate39 command is located in the following directories on the IBM TivoliAccess Manager Base CD for your particular platform. You must copy these files tothe temporary directory on your system before starting the upgrade process.v For AIX systems:






pdbackup

PurposeBacks up, restores, and extracts Access Manager data.

Syntaxpdbackup –action backup –list path_to_backup_ list [–path path][–file filename][–usage ][–?]

pdbackup –action restore –file filename [–path path][–usage][–?]

pdbackup –action extract –file filename –path path[–usage][–?]

DescriptionUse this command to back up and restore Access Manager data.

Archived files are stored in one of the following ways:v On UNIX systems, the archive is stored as a single .tar file in the

/var/PolicyDirector/pdbackup default directory. The default file name is asfollows:list_date.time.tar

where list is the name specified by the –list option and date.time is the currentdate and timestamp of the archived file.

v On Windows systems, the archive is stored as a directory tree in the \runtime_environment_path\pdbackup default directory. A .dir extension is appended tothe archive file or directory. Registry keys (.reg extensions) are stored at thebase of the directory tree.

Files are restored in one of the following ways:v On UNIX systems, archived files are restored to the root directory unless you

specify the –path path option, which enables you to restore files to a specificdirectory tree.

v On Window system, archived files are restored to their original directory. Thereis no –path option available.

You can also use this command during the upgrade process to extract files in asingle directory (without a directory tree structure). Note that Windows registrykeys are not updated with the –a extract option.

OptionsNote that you can shorten an option name, but the abbreviation must beunambiguous. For example, you can type a for action. However, values for optionscannot be shortened.

–action [backup | restore | extract]Specifies to backup, restore, or extract data.

–list path_to_backup_listSpecifies the fully qualified path to the backup list file—an ACSII filecontaining various stanzas. This option is required when using the –abackup option.


–path pathSpecifies one of the following:v If specified with the –a backup option, specifies the path where you

want backed up files stored. If you do not specify a path when using the–a backup option, the default path is one of the following:– On UNIX systems, the default path is as follows:

/var/PolicyDirector/pdbackup/

– On Windows systems, the default path is as follows:runtime_dir\pdbackup\

where runtime_dir specifies the directory where the Access Managerruntime environment is installed.

v If specified with the –a restore option on UNIX systems only, indicatesto restore archived files in the specified path. By default, the restore pathon is the directory used when backing up data. On Windows system, therestore process does not support the –p option.

v If specified with the –a extract option, specifies the directory namewhere you want extracted files stored. There is no default path. The –poption is required when using the –a extract option.

–file [filename]Specifies one of the following:v If specified with the –a backup option, specifies a file name other than

the list_date.time [.tar|.dir] default file name.v If specified with the –a restore option, specifies the name and fully

qualified path of the archive file to restore. There is no default path. Thisoption is required when using the –a restore option.

v If specified with the –a extract option, specifies the name and fullyqualified path of the archive file to extract. There is no default path. Thisoption is required when using the –a extract option.

–usageSpecifies pdbackup command usage.

–? Specifies pdbackup command usage.

UNIX Examples1. The following example performs a standard back up with default settings:

pdbackup -a backup -l /opt/PolicyDirector/etc/pdbackup.1st

This results in a file named pdbackup.1st_date.time.tar, located in the/var/PolicyDirector/pdbackup directory.

2. The following example performs a back up, creating the default archive file inthe /var/backup directory:pdbackup -a backup -l /opt/PolicyDirector/etc/pdbackup.1st-p /var/backup

This results in a file named pdbackup.1st_date.time.tar, located in the/var/backup directory.

3. The following example performs a back up, creating a file namedpdarchive.tar in the following default path:pdbackup -a backup -list /opt/PolicyDirector/etc/pdbackup.1st-f pdarchive


The default archive extension (.tar) is appended to the pdarchive file name.This file is stored in the /var/PolicyDirector/pdbackup directory.

4. The following example restores the archive file in the default location:pdbackup -a restore -f pdbackup.1st_29June2002.07_24.tar

5. The following example restores the archive file from the /var/pdback directory:pdbackup -a restore -f /var/pdback/pdbackup.1st_29Jun2002.07_25.tar

6. The following example restores the archive file from the /var/pdback directoryto a directory named /pdtest:pdbackup -a restore -p pdtest -f /var/pdback/pdbackup.1st_29Jun2002.07_25.tar

7. The following example extracts the contents of an archive file to a directorynamed e:/pdextract. The –a extract option is used during the upgrade process.pdbackup -a extract -p e:\pdextract -f c:\pdbackup\pdbackup.1st_29Jun2002.07_25.tar

If the pdextract directory does not exist, it is created. Note that all files in thearchive file are copied to this single directory. No subdirectories are created.

Windows Examples1. The following example performs a standard backup with default settings:

pdbackup -a backup -l base_dir\etc\pdbackup.1st

This results in a file named pdbackup.1st_date.time.dir, located in thebase_dir\pdbackup directory.

2. The following example performs a back up using the default archive file nameand stores the file in the c:\pdback directory:pdbackup -a backup -l base_dir\etc\pdbackup.1st -path c:\pdback

3. The following example performs a back up using the default path with a filenamed pdarchive.dir:pdbackup -a backup -l base_dir\etc\pdbackup.1st -f pdarchive

The default archive extension (.dir) is applied to the pdarchive file name. Thefile is stored in the base_dir\pdbackup directory.

4. The following example performs a back up to the \pdback directory on the Fdrive:pdbackup -a backup -l pdbackup.1st -p f:\pdback

5. The following example restores the archive file from the default directory:pdbackup -a restore -f base_dir\etc\pdbackup.1st_29Jun2002.07_24.dir

6. The following example restores files from the c:\pdbackup directory:pdbackup -a restore -f h:\pdbackup\pdbackup.1st_29Jun2002.07_25.dir

7. The following example extracts the contents of an archive to the e:\pdextractdirectory from the c:\pdback directory:pdbackup -a extract -p e:\pdextract-f c:\pdback pdbackup.1st_29Jun2002.07_25.dir

AvailabilityThe pdbackup command is located in the following default installation directoriesand on the IBM Tivoli Access Manager Base CD for your particular platform asshown:


Note: Ensure that you copy these files to a temporary directory on your systembefore starting the upgrade process.

v For AIX systems:/opt/PolicyDirector/bin/pdbackup


v For HP-UX systems:/opt/PolicyDirector/bin/pdbackup

cd_path/hp/migrate

v For Solaris systems:/opt/PolicyDirector/bin/pdbackup

cd_path/solaris/migrate

v For Windows systems:install_dir\bin\pdbackup

cd_path\windows\migrate


pdjrtecfg

PurposeConfigures the Access Manager Java Runtime Environment. Note that using thiscommand does not overwrite Jar files that already exist in the jre_home\lib\extdirectory, except the PD.jar file, which is overwritten if the file exists.

Syntaxpdjrtecfg –action config [–java_home { jre_path} ][–rspfile filename]

pdjrtecfg –action unconfig –java_home { all | jre_path} [–rspfile filename][–remove_common_jars {yes|no}]

pdjrtecfg [–operations][–usage][–?][–help]

Options–action {config | unconfig}

Specifies to configure or unconfigure the Access Manager JavaRuntime Environment.

–help Prints options available for use with the pdjrtecfg command.

–java_home jre_pathSpecifies the fully-qualified path to the Java Runtime Environment(i.e. the directory ending in JRE). For example:c:\Program Files\IBM\JAVA13\JRE

During unconfiguration (–action unconfig), you can use the allsuboption, which unconfigures all configured JREs. Duringconfiguration (–action config), the jre_path variable is not required.If a path is not specified, the current JRE (specified in the path) isused.

–remove_common_jars {yes | no}During unconfiguration only, specifies to delete (yes) or not todelete (no) other IBM related jars, such as logging and security jarfiles.

–operations Prints out all the valid command line options for this program.

–rspfile filenameSpecifies to use a response file named filename. There is not adefault response file name.

–usage Prints out the usage information for this program.

–? Prints the usage information for this program.


pdupgrade

PurposeExports, imports, and restores Access Manager information. On Windows systems,this command is called automatically by InstallShield. On UNIX systems, you needonly use the –export and –restore options, if necessary.

Syntaxpdupgrade {–export | –import | –restore}

Options–export On UNIX systems only, copies files from the Access Manager,

Version 3.7.1, installation that are needed for the upgrade toVersion 3.9. User information, including configuration files, registrykeys, and audit logs are copied to the /tmp/PolicyDirectordirectory.

–import Copies and converts user data previously stored in the temporarydirectory (using the –export option) to one of the following archivedirectories:v On UNIX systems: /var/PolicyDirector/save37v On Windows systems: \install_path\save37 where install_path

specifies the directory where Access Manager, Version 3.9, isinstalled.

–restore Specifies to restore the Access Manager, Version 3.7.1, environmentin case the installation of Version 3.9 fails. Before using this option,you must reinstall Access Manager, Version 3.7.1. On Windowssystems, the registry information also is restored. On UNIXsystems, the appropriate symbolic links are restored. For moreinformation, see “Restoring a system to Version 3.7.1” on page 195.

AvailabilityThe pdupgrade command is located in the following directories on the IBM TivoliAccess Manager Base CD for your particular platform. You must copy these files tothe temporary directory on your system before starting the upgrade process.v For AIX systems:







Appendix E. 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 Licensing IBM Corporation North Castle Drive Armonk, NY10504-1785 U.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 Corporation Licensing 2-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 Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758 U.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.

Some code distributed with the product is from third parties, which havealternative licensing terms. These terms are reproduced below.

XML Parser Toolkit LicenseCopyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd


Permission is hereby granted, free of charge, to any person obtaining a copy of thissoftware and associated documentation files (the ″Software″), to deal in theSoftware without restriction, including without limitation the rights to use, copy,modify, merge, publish, distribute, sublicense, and/or sell copies of the Software,and to permit persons to whom the Software is furnished to do so, subject to thefollowing conditions:

The above copyright notice and this permission notice shall be included in allcopies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED ″AS IS″, WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIESOF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ANDNONINFRINGEMENT.

IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLEFOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN ANACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF ORIN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGSIN THE SOFTWARE.

Pluggable Authentication Module LicenseCopyright (C) 1995 by Red Hat Software, Marc Ewing Copyright (c) 1996-8,Andrew G. Morgan <[email protected]>

All rights reserved

Redistribution and use in source and binary forms, with or without modification,are permitted provided that the following conditions are met:1. Redistributions of source code must retain the above copyright notice, and the

entire permission notice in its entirety, including the disclaimer of warranties.2. Redistributions in binary form must reproduce the above copyright notice, this

list of conditions and the following disclaimer in the documentation and/orother materials provided with the distribution.

3. The name of the author may not be used to endorse or promote productsderived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED ″AS IS″’ AND ANY EXPRESS OR IMPLIEDWARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULARPURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLEFOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, ORCONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ONANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAYOUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THEPOSSIBILITY OF SUCH DAMAGE.

TrademarksThe following terms are trademarks or registered trademarks of InternationalBusiness Machines Corporation in the United States, other countries, or both:

Appendix E. Notices 235

AIXDB2IBMIBM logoMVSOS/390SecureWayTivoliTivoli logoUniversal DatabaseWebSpherezSeriesz/OS

Lotus, Lotus Notes, and Notes are trademarks of Lotus Development Corporationand/or IBM Corporation.

Domino is a trademark of International Business Machines Corporation and LotusDevelopment 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, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States, other countries, or both.Java and allJava-based trademarks and logos are trademarks or registered trademarks of SunMicrosystems, Inc. in the United States and other countries.

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.


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) In computer security, acollection of all access rights for one object. (2) Incomputer security, a list associated with an object thatidentifies all the subjects that can access the object andtheir access rights; for example, a list associated with afile that identifies users who can access the file andidentifies their access rights to that file.

access permissions. Permissions that apply to theentire object or permissions that apply to attributeaccess classes.

actions. ACL permission attributes.

ACL. See access control list.

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 used to verify the user ofan information system or protected resources.

authorization. (1) In computer security, the rightgranted to a user to communicate with or make use ofa computer system. (2) An access right. (3) The processof granting a user either complete or restricted accessto an object, resource, or function.

Bbind. 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.

Ccertificate. In e-commerce, a digital document thatbinds 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. In e-commerce, an organizationthat issues certificates. The certificate authorityauthenticates the certificate owner’s identity and theservices that the owner is authorized to use, issues newcertificates, renews existing certificates, and revokescertificates belonging to users who are no longerauthorized to use them.

cipher. Encrypted data that is unreadable until it hasbeen converted into plain data (decrypted) with a key.

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.

credentials. Detailed information, acquired duringauthentication, that describes the user, any groupassociations, and other security-related identityattributes. Credentials can be used by any AccessManager service that requires information about theuser. Credentials allow Access Manager to securelyperform a multitude of services, such as authorization,auditing, and delegation. For example, the AccessManager authorization service uses the user credentialto determine whether the user is authorized to performspecific operations on a protected resource.

Ddaemon. A program that runs unattended to performa standard service. Some daemons are triggeredautomatically to perform their task; others operateperiodically.

DCE. See distributed computing environment.

directory schema. Entries in a directory are made upof a collection of attributes and their associated values.Attributes may have one or multiple values. In order toidentify a particular value in an entry, the attribute typename is specified along with the value, as in cn=JohnDoe. This is referred to as an attribute:value pair. Everyentry contains an objectClass attribute that identifies


what type of information the entry contains. In fact, theobject class dictates which other attributes may bepresent in an entry. The directory schema defines thevalid attribute types and object classes that may appearin the directory. Attribute type definitions define themaximum length and syntax of its values. Object classdefinitions specify which attributes must be present inan object of that class, as well as attributes that may bepresent.

distinguished name (DN). Every entry in a directoryhas a distinguished name. The distinguished name isthe name that uniquely identifies an entry in thedirectory. A distinguished name is made up ofattribute:value pairs, separated by commas.

distributed computing environment (DCE). The OpenSoftware Foundation specification (or a product derivedfrom this specification) that assists in networking. Thedistributed computing environment provides suchfunctions as authentication, directory service, andremote procedure call.

digital signature. Data that is appended to, or is acryptographic transformation of, a data unit and thatenables the recipient of the data unit to verify thesource and integrity of the unit and to recognizepotential forgery.

DN. See distinguished name.

domain. (1) That part of a computer network in whichthe data processing resources are under commoncontrol. (2) In a database, all the possible values of anattribute or a data element. (3) 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 (FQDN) of a host system is ralvm7.vnet.ibm.com,each of the following is a domain name:

v ralvm7.vnet.ibm.com

v vnet.ibm.com

v ibm.com

Eencryption. The process of transforming data into anunintelligible form in such a way that the original dataeither cannot be obtained or can be obtained only byusing a decryption process.

FFile Transfer Protocol (FTP). In the Internet suite ofprotocols, an application layer protocol that uses TCPand Telnet services to transfer bulk-data files betweenmachines or hosts.

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.

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).

IP. See Internet Protocol.

Kkey. A sequence of symbols that is used with acryptographic algorithm for encrypting or decryptingdata. See private key and public key.

key database file. See key ring.

key file. See key ring.

key pairs. A public key and a private key. When thekey pair is used for encryption, the sender uses thepublic key to encrypt the message, and the recipientuses the private key to decrypt the message. When thekey pair is used for signing, the signer uses the privatekey to encrypt a representation of the message, and therecipient uses the public key to decrypt therepresentation of the message for signature verification.

key ring. A file that contains public keys, private keys,trusted roots, and certificates.

LLDAP. See Lightweight Directory Access Protocol.

ldif2db. This program is used to load entries specifiedin text LDAP Directory Interchange Format (LDIF) intoa directory stored in a relational database. The databasemust already exist. ldif2db may be used to add entriesto an empty directory database or to a database thatalready contains entries.


Lightweight Directory Access Protocol (LDAP). Anopen protocol that (a) uses TCP/IP to provide access todirectories that support an X.500 model and (b) doesnot 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.

Mmanagement server. See policy server.

metadata. Data that describes the characteristics ofstored data; descriptive data.

migration. The installation of a new version or releaseof a program to replace an earlier version or release.

Oobject class definitions. Every entry contains anobjectClass attribute that identifies what type ofinformation the entry contains. In fact, the object classdictates which other attributes may be present in anentry. The directory schema defines the valid attributetypes and object classes that may appear in thedirectory. Attribute type definitions define themaximum length and syntax of its values. Object classdefinitions specify which attributes must be present inan object of that class, as well as attributes that may bepresent.

Ppolicy. A set of rules that are applied to managedresources.

policy data. Includes both password strength policydata and login data.

policy server. Maintains location information aboutother Access Manager servers in the secure domain.When policy changes affect the master authorizationpolicy database, the policy server is responsible forupdating all authorization database replicas in thedomain.

POP. See protected object policy.

protected object policy (POP). A type of AccessManager security policy that dictates additionalconditions for accessing a protected resource after a

successful ACL policy check. Examples of POPs includetime-of-day access and quality 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. A key that is known only to its owner.Contrast with public key.

public key. A key that is made available 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 replica is a server that runs a copy of thedirectory. This replicated server can keep a copy of theentire directory or just one tree of that directory. Anyupdate to a replica server is referred to the masterserver. If the master server fails, you always have acopy of the directory trees on the replica server. Usingthe replica server also improves the response time.

response file. A file that contains a set of predefinedanswers to questions asked by a program and that isused in place of user dialog.

RSA. A system for public-key cryptography used forencryption and authentication. It was invented in 1977by Ron Rivest, Adi Shamir, and Leonard Adleman. Thesystem’s security depends on the difficulty of factoringthe product of two large prime 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.

Glossary 239

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.

service. Work performed by a server. This may meanserving simple requests for data to be sent or stored (aswith file servers, HTTP servers, e-mail servers, andfinger servers), or it may be more complex work suchas that of 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, can indicate that theinstallation uses response files instead of user dialogs.

SSL. See Secure Sockets Layer.

suffixes. A suffix is a distinguished name thatidentifies the top entry in a locally held directoryhierarchy. Because of the relative naming scheme usedin Lightweight Directory Access Protocol (LDAP), thisdistinguished name is also the suffix of every otherentry within that directory hierarchy. A directory servermay have multiple suffixes, each identifying a locallyheld directory hierarchy.

Ttoken. (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. The Open Systems Interconnection(OSI) equivalent of port numbers in TCP/IP. Alsocalled 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.

Uuser. Any person, organization, process, device,program, protocol, or system that uses a serviceprovided by others.


Printed in U.S.A.

GC32-0844-00

Date post:	29-Jul-2020
Category:	Documents
Upload:	others
View:	6 times
Download:	0 times