tivoli secureway policy director base for hp-ux...

Tivoli SecureWay Policy DirectorBase for HP-UXInstallation Guide

Version 3.7January 2001

Tivoli SecureWay Policy Director

Base for HP-UX Installation Guide

Copyright Notice©Copyright IBM Corporation 2001 All rights reserved. May only be used pursuant to a Tivoli Systems Software License Agreement, an IBM Software License Agreement, or Addendum for Tivoli Products to IBM Customer or License Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of IBM Corporation. IBM Corporation grants you limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry the IBM Corporation copyright notice. No other rights under copyright are granted without prior written permission of IBM Corporation. The document is not intended for production and is furnished “as is” without warranty of any kind. All warranties on this document are hereby disclaimed, including the warranties of merchantability and fitness for a particular purpose.U.S. Government Users Restricted Rights—Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corporation.

TrademarksIBM, the IBM logo, Tivoli, the Tivoli logo, AIX, Policy Director, and SecureWay are trademarks or registered trademarks of International Business Machines Corporation or Tivoli Systems Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.UNIX is a registered trademark of The Open Group in the United States and other countries.Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.Other company, product, and service names may be trademarks or service marks of others.

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

Tivoli SecureWay Policy Director Base for HP-UX Installation Guide i

ContentsPreface ................................................................................................. i

Who Should Read This Guide............................................................................iWhat This Guide Contains .................................................................................iTypeface Conventions .......................................................................................iiRelated Policy Director Documents ................................................................ iiiAccessing Online Documentation ....................................................................ivOrdering Documentation ..................................................................................ivProviding Feedback about Product Documentation ..........................................vContacting Customer Support ...........................................................................v

Chapter 1 — Getting Started1.1 Overview of Installation Process................................................................... 1-1

1.2 Overview of the Upgrade Process ................................................................. 1-3

Chapter 2 — Policy Director Packages and System Requirements2.1 Policy Director Base for HP-UX Packages ................................................... 2-2

2.2 Hardware and Software Requirements.......................................................... 2-3

2.2.1 Operating System Versions .............................................................. 2-3

2.2.2 Supported DCE Environments ......................................................... 2-3

2.2.3 LDAP Interoperability...................................................................... 2-4

2.2.4 Domino Support ............................................................................... 2-4

Chapter 3 — Planning a Policy Director Installation3.1 Defining Security Requirements ................................................................... 3-2

3.2 Combining Policy Director Base and Applications ...................................... 3-3

3.3 Policy Director Base for HP-UX................................................................... 3-4

3.3.1 Policy Director Runtime Environment............................................. 3-5

3.3.2 Policy Director Management Server ................................................ 3-5

3.3.3 Policy Director Authorization Server............................................... 3-5

3.3.4 Policy Director Authorization Application Development Kit.......... 3-5

3.4 Policy Director Management Console .......................................................... 3-6

3.5 Policy Director Applications ......................................................................... 3-7

3.5.1 Policy Director WebSEAL............................................................... 3-7

3.5.2 Policy Director NetSEAL................................................................. 3-7

3.6 External Software Requirements................................................................... 3-8

ii Version 3.7

3.6.1 DCE Infrastructure............................................................................3-8

3.6.2 User Registry ....................................................................................3-9

3.7 Creating a New Secure Domain...................................................................3-10

3.7.1 A Typical Policy Director New Secure Domain Installation..........3-12

3.8 Adding a Policy Director Server System to a Secure Domain ....................3-13

3.9 Adding a Policy Director Runtime System to a Secure Domain .................3-14

3.9.1 Using Policy Director without DCE ...............................................3-14

3.10 Installing a Policy Director Development Environment..............................3-15

Chapter 4 — Configuring IBM LDAP4.1 Installing IBM SecureWay Directory ............................................................4-2

4.1.1 Installing an IBM LDAP Server .......................................................4-2

4.1.2 Optimizing IBM LDAP Server Performance ...................................4-3

4.1.3 Installing IBM LDAP Server Patches...............................................4-4

4.1.4 Installing an IBM LDAP Client ........................................................4-5

4.1.5 Installing an IBM LDAP Client Patch ..............................................4-6

4.2 Adding Policy Director Suffixes....................................................................4-7

4.3 Installing or Upgrading Policy Director Security Schema.............................4-8

4.3.1 Installing Policy Director Security Schema......................................4-8

4.3.2 Upgrading Policy Director Security Schema..................................4-10

4.4 Configuring LDAP Access Control on ACLs..............................................4-11

4.4.1 Adding the LDAP Server Entry ......................................................4-12

4.4.2 Adding the Organization Entry .......................................................4-13

4.4.3 Adding the Policy Director Group to LDAP ACLs........................4-14

Chapter 5 — Configuring a Netscape LDAP Server5.1 Installing a Netscape Server and IBM Client.................................................5-2

5.1.1 Installing a Netscape LDAP Server ..................................................5-2

5.1.2 Installing an LDAP Client ................................................................5-2

5.2 Adding Suffixes for Netscape Directory Server ............................................5-3

5.2.1 Adding a Suffix for GSO ..................................................................5-4

5.3 Installing or Updating Policy Director Security Schema...............................5-6

5.3.1 Installing Policy Director Security Schema......................................5-6

5.3.2 Updating Policy Director Security Schema ......................................5-9

5.4 Configuring SSL Access for Netscape Directory Server.............................5-10

Tivoli SecureWay Policy Director Base for HP-UX Installation Guide iii

5.4.1 Obtaining a Server Certificate........................................................ 5-11

5.4.2 Installing the Server Certificate...................................................... 5-13

5.4.3 Enabling SSL Access ..................................................................... 5-15

Chapter 6 — Configuring SSL Access for IBM LDAP6.1 Overview of LDAP SSL Configuration ........................................................ 6-2

6.2 Configuring the LDAP Server for SSL Access............................................. 6-3

6.2.1 Creating the Key Database File and the Certificate ......................... 6-4

6.2.2 Obtaining a Personal Certificate from a Certificate Authority......... 6-6

6.2.3 Creating and Extracting a Self-signed Certificate............................ 6-7

6.2.4 Enabling SSL Access on the LDAP Server ..................................... 6-9

6.3 Configuring the LDAP Client for SSL Access ........................................... 6-11

6.3.1 Creating a Key Database File......................................................... 6-12

6.3.2 Adding a Signer Certificate............................................................ 6-14

6.3.3 Testing SSL Access........................................................................ 6-15

6.4 Configuring LDAP Server and Client Authentication ................................ 6-16

6.4.1 Creating a Key Database File......................................................... 6-17

6.4.2 Obtaining a Personal Certificate from a Certificate Authority....... 6-19

6.4.3 Creating and Extracting a Self-signed Certificate.......................... 6-20

6.4.4 Adding a Signer Certificate............................................................ 6-22

6.4.5 Testing the SSL access ................................................................... 6-23

Chapter 7 — Installing and Configuring Policy Director7.1 Installing Policy Director Runtime Environment.......................................... 7-3

7.2 Installing Policy Director Management Server ............................................. 7-4

7.3 Installing Policy Director Authorization Server............................................ 7-5

7.4 Installing Policy Director Authorization ADK ............................................. 7-6

7.5 Configuring Policy Director Runtime Environment ..................................... 7-7

7.5.1 Configuring Runtime Environment for a New Secure Domain ....... 7-7

7.5.2 Configuring Runtime Environment into an Existing Secure Domain7-8

7.6 Configuring Policy Director Management Server....................................... 7-10

7.6.1 Configuring Management Server with an LDAP User Registry.... 7-11

7.6.2 Configuring Management Server with a DCE User Registry ........ 7-14

7.7 Configuring Policy Director Authorization Server ..................................... 7-16

7.7.1 Configuring Authorization Server with an LDAP User Registry .. 7-17

iv Version 3.7

7.7.2 Configuring Authorization Server with a DCE User Registry .......7-18

Chapter 8 — Upgrading Policy Director8.1 Policy Director Version 3.7 Upgrade Support ...............................................8-2

8.1.1 Version 3.7 Package Naming Conventions ......................................8-2

8.1.2 Components That Are Upgraded ......................................................8-3

8.1.3 Components that Are Not Upgraded.................................................8-3

8.1.4 Supported Upgrade Paths..................................................................8-3

8.2 Overview of the Upgrade Process..................................................................8-4

8.2.1 Preparation of a Version 3.6 System for Upgrading.........................8-4

8.2.2 Installation of New Versions of Supporting Software ......................8-4

8.2.3 Removal of Policy Director Packages that are not Upgraded...........8-5

8.2.4 Extraction of Policy Director Version 3.7 Packages ........................8-5

8.2.5 Upgrade of Policy Director Version 3.7 Package Configurations ....8-6

8.2.6 Upgrading the Version 3.6 ACLs .....................................................8-6

8.3 Preserving the Policy Director Version 3.6 Configuration ............................8-7

8.3.1 Obtaining and Installing the Migration Tool ....................................8-7

8.3.2 Preserving Policy Director Configuration Data ................................8-8

8.3.3 Preserving Customized Configuration File Entries ..........................8-8

8.4 Upgrading Software Dependencies................................................................8-9

8.4.1 Upgrading the DCE Infrastructure....................................................8-9

8.4.2 Upgrading LDAP Servers and Clients ..............................................8-9

8.5 Extracting Runtime Environment Files........................................................8-10

8.6 Extracting Management Server Files ...........................................................8-12

8.7 Extracting Authorization Server Files..........................................................8-14

8.8 Extracting Authorization ADK Files ...........................................................8-15

8.9 Upgrading the Runtime Environment Configuration...................................8-16

8.9.1 Configuring the Upgrade Migration File ........................................8-16

8.9.2 Upgrading the Runtime Environment .............................................8-16

8.10 Upgrading the Management Server Configuration......................................8-18

8.11 Upgrading the Authorization Server Configuration.....................................8-20

8.12 Upgrading ACLs from Policy Director 3.6..................................................8-21

8.13 Troubleshooting ...........................................................................................8-23

8.13.1 Running the Upgrade Scripts Manually..........................................8-23

Tivoli SecureWay Policy Director Base for HP-UX Installation Guide v

8.13.2 Restoring Saved Data Manually..................................................... 8-23

Chapter 9 — Removing Policy Director Base9.1 Unconfiguring Policy Director Authorization Server ................................... 9-2

9.1.1 Unconfiguring Authorization Server with a DCE User Registry..... 9-3

9.1.2 Unconfiguring Authorization Server with an LDAP User Registry 9-3

9.2 Unconfiguring Policy Director Management Server..................................... 9-4

9.2.1 Unconfiguring Management Server with a DCE User Registry ...... 9-5

9.2.2 Unconfiguring Management Server with an LDAP User Registry.. 9-5

9.3 Unconfiguring Policy Director Runtime Environment ................................. 9-6

9.4 Removing Policy Director Authorization ADK............................................ 9-7

9.5 Removing Policy Director Authorization Server .......................................... 9-8

9.6 Removing Policy Director Management Server ........................................... 9-9

9.7 Removing Policy Director Runtime Environment ...................................... 9-10

vi Version 3.7

Preface

Tivoli SecureWay Policy Director Base for HP-UX Installation Guide i

Preface

This document contains information about how to install and configure Tivoli SecureWay Policy Director Base for HP-UX, Version 3.7.

Policy Director is a standalone authorization and security management solution that provides end-to-end security of resources over geographically dispersed intranets and extranets.

Policy Director provides authentication, authorization, data security, and resource-management services. You can use Policy Director in conjunction with standard Interned-based applications to build secure and well-managed intranets and extranets

Who Should Read This Guide

The target audience for this installation guide includes:

� Security administrators

� System installation and deployment administrators

� Network system administrators

� IT architects

� Application developers

What This Guide Contains

This document contains the following sections:� Chapter 1, ”Getting Started”

Provides an overview of the steps necessary to install and configure Policy Director Base for HP-UX.

� Chapter 2, ”Policy Director Packages and System Requirements”Describes the Policy Director Base for HP-UX software packages, and lists hardware and software requirements.

� Chapter 3, ”Planning a Policy Director Installation”Describes Policy Director deployment scenarios, and provides information needed to plan a Policy Director installation

Preface

ii Version 3.7

� Chapter 4, ”Configuring IBM LDAP”

Describes how to configure an IBM SecureWay Directory LDAP server and client to support Policy Director.

� Chapter 5, ”Configuring a Netscape LDAP Server”

Describes how to configure a Netscape LDAP server to support Policy Director.

� Chapter 6, ”Configuring SSL Access for IBM LDAP”Describes how to configure SSL communication between an IBM SecureWay Director LDAP Client and an IBM SecureWay Director LDAP Server.

� Chapter 7, ”Installing and Configuring Policy Director”Describes how to install and configure a new Policy Director installation.

� Chapter 8, ”Upgrading Policy Director”Describes how to upgrade an existing Policy Director system.

� Chapter 9, ”Removing Policy Director Base”Describes how to unconfigure and remove Policy Director Base packages.

Typeface Conventions

This guide uses several typeface conventions for special terms and actions. These conventions have the following meaning:

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

Italics Variables, command arguments, and values you must provide appear in italics. Titles of publications and special words or phrases that are emphasized also appear in italics.

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

Preface

Tivoli SecureWay Policy Director Base for HP-UX Installation Guide iii

Related Policy Director Documents

The following table summarizes the available Policy Director documentation:

Tivoli SecureWay Policy Director Technical Documents

Installation Guides

Tivoli SecureWay Policy Director Base for AIX Installation Guide

Tivoli SecureWay Policy Director Base for HP-UX Installation Guide (this document)

Tivoli SecureWay Policy Director Base for Solaris Installation Guide

Tivoli SecureWay Policy Director Base for Windows Installation Guide

Tivoli SecureWay Policy Director WebSEAL Installation Guide

Tivoli SecureWay Policy Director NetSEAL Installation Guide

Tivoli SecureWay Policy Director Management Console Installation Guide

Administration Guides

Tivoli SecureWay Policy Director Base Administration Guide

Tivoli SecureWay Policy Director WebSEAL Administration Guide

Tivoli SecureWay Policy Director NetSEAL Administration Guide

Tivoli SecureWay Policy Director Management Console Administration Guide

Developer References

Tivoli SecureWay Policy Director Authorization ADK Developer Reference

Tivoli SecureWay Policy Director WebSEAL Developer Reference

Supplemental Documentation (updated regularly on the Tivoli support site)

Tivoli SecureWay Policy Director Release Notes

Tivoli SecureWay Policy Director Lotus Domino Registry Supplement

Tivoli SecureWay Policy Director Performance Tuning Guide

Preface

iv Version 3.7

Accessing Online Documentation

The Tivoli Customer Support Web site (http://www.tivoli.com/support/) provides links to the following documentation information:

� Technical information, including release notes, installation and configuration guides, administration guides, and developer references.

� Frequently Asked Questions (FAQs)

� Software download information

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

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

You can locate Policy Director technical documentation, by product version, at: http://www.tivoli.com/support/Prodman/html/AB.html#Security

The documentation for some products is available in PDF and HTML formats. Translated documents are also available for some products.

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

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

Business Partners should refer to the Preface section entitled “Ordering Documentation” for more information about obtaining Tivoli technical documentation.

Ordering Documentation

Order Tivoli documentation online at http://www.tivoli.com/support/Prodman/html/pub_order.html or by calling one of the following telephone numbers:

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

� Canadian customers: (800) 426-4968

http://www.tivoli.com/support/Prodman/html/AB.html#Security

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

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

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

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

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

http://www.tivoli.com/support/smb/index.html

Preface

Tivoli SecureWay Policy Director Base for HP-UX Installation Guide v

Providing Feedback about Product Documentation

We are very interested in hearing about your experience with Tivoli products and documentation, and we welcome your suggestions for improvements. If you have comments or suggestions about our products and documentation, contact us in one of the following ways:

� Send e-mail to [email protected].

� Fill out our customer feedback survey at http://www.tivoli.com/support/survey/.

Contacting Customer Support

The Tivoli Customer Support Handbook at:

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

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

� Registration and eligibility

� How to contact support, depending on the severity of your problem

� Telephone numbers and e-mail addresses, depending on the country you are in

� What information you should gather before contacting support

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

mailto:[email protected]

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

Preface

vi Version 3.7

Tivoli SecureWay Policy Director Base for HP-UX Installation Guide 1–1

1Getting Started

This chapter provides an overview of each of the tasks required to install Policy Director on HP-UX, and directs you to the sections of this book that assist you with each task.� Overview of Installation Process (Section 1.1)� Overview of the Upgrade Process (Section 1.2)

1.1 Overview of Installation ProcessTo install and configure Policy Director Base for HP-UX on an HP-UX system, complete the following steps:

1. Review the list of packages that comprise Policy Director Base for HP-UX. Understand the functions that each package provides. � See Section 2.1: “Policy Director Base for HP-UX Packages”.

2. Verify that your system has sufficient memory and disk space. � See Section 2.2: “Hardware and Software Requirements”

3. Decide which Policy Director combination of Policy Director packages you want to install. Ensure that you understand the business security requirements for which Policy Director is being deployed. Review the Policy Director installation and configuration options.� See Chapter 3, ”Planning a Policy Director Installation” .

4. Install any necessary DCE infrastructure.� Verify that you have the correct version of the DCE software. See

Section 2.2.2: “Supported DCE Environments”.� For installation information, see the HP DCE documentation.

Chapter 1: Getting Started

1–2 Version 3.7

5. If you are using an LDAP user registry, install any necessary software.� If you are using IBM SecureWay Directory LDAP, you can get the

necessary software on the Policy Director Base CD-ROM.� If you are using a Netscape LDAP server, verify that you have the

correct version. See Section 2.2.3: “LDAP Interoperability”. See the Netscape LDAP product documentation for installation instructions.

Note: If you are using a Lotus Domino user registry, see the Tivoli SecureWay Policy Director Lotus Domino Registry Supplement.

6. If you are using an IBM SecureWay Policy Director, configure the LDAP server and LDAP client to support Policy Director.� See Chapter 4, ”Configuring IBM LDAP”.

7. If you are using a Netscape LDAP server, configure the LDAP server to support Policy Director.� See Chapter 5, ”Configuring a Netscape LDAP Server”

8. If you are using IBM SecureWay Policy Director LDAP, you can configure SSL communication between the LDAP server and LDAP clients.� See Chapter 6, ”Configuring SSL Access for IBM LDAP”

9. Determine if you are installing a new Policy Director deployment or upgrading an existing deployment.� For new Policy Director installations, follow the installation and

configuration instructions in Chapter 7, ”Installing and Configuring Policy Director”.

� If you are upgrading an existing Policy Director installation, see Section 1.2: “Overview of the Upgrade Process”.

10. If you need to reinstall Policy Director after you have installed and configured it, be sure to unconfigure and remove your existing installation first.� See Chapter 9, ”Removing Policy Director Base”.

Overview of the Upgrade Process


1.2 Overview of the Upgrade Process

Policy Director Version 3.7 supports an upgrade from Policy Director Version 3.6. If you are upgrading from Policy Director Version 3.6, review the following chapters:

� Chapter 4, ”Configuring IBM LDAP”

If Policy Director Version 3.6 used an IBM LDAP user registry, you must update the LDAP schema file.

� Chapter 5, ”Configuring a Netscape LDAP Server”

If Policy Director Version 3.6 used a Netscape LDAP user registry, you must update the LDAP schema file.

� Chapter 8, ”Upgrading Policy Director”

Chapter 1: Getting Started

1–4 Version 3.7


2Policy Director Packages and System Requirements

This chapter contains the following sections:� Policy Director Base for HP-UX Packages (Section 2.1)� Hardware and Software Requirements (Section 2.2)

Chapter 2: Policy Director Packages and System Requirements

2–2 Version 3.7

2.1 Policy Director Base for HP-UX PackagesThe following table describes the Policy Director packages that are distributed on the Policy Director Base for HP-UX CD:

Component Package Description

Runtime Environment

PDRTE Policy Director Runtime Environment contains libraries and supporting files required by all other Policy Director packages. PDRTE must be installed on any machine that will contain other Policy Director packages.

PDFramework This package combines:• Management Server• Authorization Server• Authorization Application Development Kit

This package provides a quick way to install all three of the above packages in one swinstall installation session.

Management Server PDMgr The Management Server is the master authorization server for the entire secure domain. It controls and maintains the master authorization policy database.

Authorization Server

PDAcld The Authorization Server handles authorization requests from third party applications that use the Policy Director Authorization API in remote mode.

Authorization Application Development Kit

PDAuthADK The Authorization Application Development Kit includes the Policy Director Authorization API. The API allows you to build applications that use the Policy Director Authorization Service. The ADK includes C example programs.

Hardware and Software Requirements


2.2 Hardware and Software RequirementsPolicy Director 3.7 requires the following amounts of memory and hard disk space: � RAM: 128 MB (minimum)� Disk space: 64 MB

2.2.1 Operating System VersionsThis release of Policy Director is supported on the following HP-UX operating system:� HP-UX 11.0

2.2.2 Supported DCE EnvironmentsThis release of Policy Director requires that DCE servers be installed and functioning on at least one system in the secure domain. Policy Director can be installed on systems with either a DCE Client or DCE server configuration.

Policy Director Base Version 3.7 for HP-UX, requires the following DCE product:� HP DCE 1.7.1

The following DCE packages are required to provide the necessary DCE kernel thread support:� B3864AA — DCE/9000 DES Libraries, U.S. and Canada Only� B6733AA — DCE/9000 Kernel Threads Support� B6734AA — DCE/9000 Kernel Threads Domestic Libraries, U.S. and

Canada Only

Chapter 2: Policy Director Packages and System Requirements

2–4 Version 3.7

2.2.3 LDAP InteroperabilityThis release of Policy Director interoperates with the following LDAP directory services products:� IBM SecureWay Directory LDAP Server Version 3.2 with IBM DB2

Version 6.0 and IBM GSKit Version 4.0. The IBM GSKit installation must include the GSKit Runtime packages gsk4bas and gsk4str.

� Netscape LDAP Version 4.1

2.2.4 Domino SupportThis release of Policy Director interoperates with the following Lotus Domino product:� Lotus Domino Server Version 4.6 and above


3Planning a Policy Director Installation

Policy Director provides a wide range of authorization and management solutions for intranets and extranets. Before you install Policy Director, you must determine what specific security and management capabilities are required of your network. With this information, you can then make the appropriate selection of components during installation.

This chapter consists of the following sections:� 3.1 Defining Security Requirements� 3.2 Combining Policy Director Base and Applications� 3.3 Policy Director Base for HP-UX� 3.4 Policy Director Management Console� 3.5 Policy Director Applications� 3.6 External Software Requirements� 3.7 Creating a New Secure Domain� 3.8 Adding a Policy Director Server System to a Secure Domain� 3.9 Adding a Policy Director Runtime System to a Secure Domain� 3.10 Installing a Policy Director Development Environment

Chapter 3: Planning a Policy Director Installation

3–2 Version 3.7

3.1 Defining Security RequirementsThe first step in planning the deployment of a Policy Director secure domain is to define the security requirements for your computing environment. Defining security requirements means determining the business policies that must apply to users, programs, and data. This step includes defining the following:� Objects to be secured� Actions permitted on each object� Users permitted to perform the actions

Enforcing a security policy requires an understanding of the flow of access requests through your network topology. This includes identifying proper roles and locations for firewalls, routers, and subnets. Deploying a security environment also requires identifying the optimal points within the network for installing software that evaluates user access requests, 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. Performance characteristics, scalability, and the need for failover capabilities should be evaluated. Integration of legacy software, databases, and applications with Policy Director software must be considered.

Once you have established the business policies that drive security requirements, you must learn how Policy Director can be deployed to fulfill those requirements. You can learn about Policy Director features and functions by reading the Policy Director Base Administration Guide. This administration guide is distributed on the Policy Director Base for HP-UX CD-ROM.

If you have Policy Director applications such as Policy Director WebSEAL or Policy Director NetSEAL, see also the administration guides for these products.

Once you have an understanding of the Policy Director features you want to deploy, read the remainder of this chapter to understand how Policy Director is packaged. You can then decide which Policy Director packages and applications can be combined to best implement your security policy.

Note: You can also read about Policy Director deployment scenarios in the IBM Redbook Tivoli SecureWay Policy Director: Centrally Managing e-business Security. See http://www.ibm.com/redbooks for more information.

Combining Policy Director Base and Applications


3.2 Combining Policy Director Base and ApplicationsThe Policy Director product family is based on a model that combines a set of servers and runtime libraries with one or more application products. The servers and runtime libraries provide a security framework that includes authentication and authorization libraries. A Management Console provides an easy-to-use graphical interface for managing Policy Director environments.

Each of the application products applies and extends these functions to implement security for specific environments. The Tivoli SecureWay Policy Director product family includes the following applications:� Policy Director WebSEAL� Policy Director NetSEAL

In addition, Policy Director provides an Application Development Kit that you can use to secure third-party applications.

Figure 3-1: Policy Director Base supports multiple applications

PolicyDirector

WebSEAL

Policy Director Management Console

PolicyDirector

NetSEAL

Third PartyApplications

Policy Director Servers and Runtime Libraries


3–4 Version 3.7

3.3 Policy Director Base for HP-UXThe Policy Director Base for HP-UX consists of two swinstall packages: PDRTE and PDFramework. Only PDRTE is required on every Policy Director system.

PDFramework contains three packages:� Management Server� Authorization Server� Authorization Application Development Kit

Each of the three packages can be installed separately.

The packages are described in the following sections:� Policy Director Runtime Environment (Section 3.3.1)� Policy Director Management Server (Section 3.3.2)� Policy Director Authorization Server (Section 3.3.3)� Policy Director Authorization Application Development Kit (Section

3.3.4)

Package Pkgadd Usage

Runtime Environment PDRTE Required on every Policy Director installation.

Management Server PDMgr Required on one and only one Policy Director system in each secure domain.

Authorization Server PDAcld Optional server

Authorization Application Development Kit

PDAuthADK Optional

Policy Director Base for HP-UX


3.3.1 Policy Director Runtime EnvironmentPolicy Director Runtime Environment contains runtime libraries and supporting files required by all other Policy Director packages. The Runtime Environment must be installed on every system that be part of a Policy Director secure domain.

The Runtime Environment does not contain any Policy Director servers. It does, however, contain runtime libraries that can be used by other applications to access Policy Director servers that are installed on other systems.

3.3.2 Policy Director Management ServerThe Management Server maintains the master authorization database for the secure domain, replicates this database throughout the secure domain, and maintains location information about other Policy Director server machines in the secure domain.

There must be one and only one Management Server in each Policy Director secure domain.

3.3.3 Policy Director Authorization ServerThe Authorization Server provides access to the Policy Director Authorization Service for third-party applications, using the Authorization API.

The Authorization Server can also be used to replicate some of the Management Server functionality. This enables achievement of optimal performance in large-scale deployments.

3.3.4 Policy Director Authorization Application Development KitThe Policy Director Authorization Application Development Kit (ADK) provides an interface to the Authorization Services through the Authorization API. Policy Director provides both C and Java Authorization APIs. The ADK also provides a sample External Authorization Server (EAS). The EAS can be used with DCE user registries to supplement and extend DCE services.


3–6 Version 3.7

3.4 Policy Director Management ConsolePolicy Director includes a graphical user interface utility for managing users, accounts, and the protected object namespace in a Policy Director secure domain. This utility is the Policy Director Management Console.

Policy Director administrators are not required to use the Policy Director Management Console. Policy Director provides a series of command line tools that can be used to complete all the necessary administration tasks.

The Policy Director Management Console is not part of the Policy Director Base for HP-UX distribution. The Policy Director Management Console is a Windows NT application, and is distributed on a separate CD.

You can install all of the software on the Policy Director Base CD before installing the Policy Director Management Console.

For more information on the Policy Director Management Console, see the Policy Director Management Console Installation Guide.

Policy Director Applications


3.5 Policy Director ApplicationsMost Policy Director deployment scenarios include installing an application that has been enabled to use Policy Director security. These applications include the Tivoli Policy Director applications WebSEAL and NetSEAL. In addition, third-party applications can be developed with the Authorization API in order to use Policy Director security.

Policy Director WebSEAL and Policy Director NetSEAL are distributed on a separate CD. These applications are summarized in the following sections:� Policy Director WebSEAL (Section 3.5.1)� Policy Director NetSEAL (Section 3.5.2)

3.5.1 Policy Director WebSEALPolicy Director WebSEAL is a high performance, secure, multi-threaded Web Server. WebSEAL applies access control policies, based on information from an authorization policy database, to HTTP, HTTPS, and NetSEAT Client requests. WebSEAL manages access control for such resources as: URLs, URL-based regular expressions, CGI programs in Perl, C, C++, HTML files, Java servlets, and Java class files.

For more information see the Policy Director WebSEAL Installation Guide and Policy Director WebSEAL Administration Guide.

3.5.2 Policy Director NetSEALPolicy Director NetSEAL is a Virtual Private Network (VPN) solution for securing all incoming TCP/IP communication. NetSEAL performs access control based on the destination port and identity of the client. NetSEAL is the security solution for authorizing and securing traditional Internet services, such as TELNET and POP3, as well as various application packages, including database systems and network management tools.

For more information see the Policy Director NetSEAL Installation Guide and Policy Director NetSEAL Administration Guide.


3–8 Version 3.7

3.6 External Software RequirementsPolicy Director requires a DCE infrastructure to support the Policy Director servers. Policy Director does not require a DCE infrastructure to support systems that use only the Policy Director Runtime libraries.

Policy Director supports several different types of user registries.

These external software requirements are described in the following sections:� DCE Infrastructure (Section 3.6.1)� User Registry (Section 3.6.2)

3.6.1 DCE InfrastructureThe Policy Director environment must contain a DCE infrastructure before you can install Policy Director. At least one system in the secure domain must contain a full DCE server installation.� If you are creating a new Policy Director secure domain, Policy Director

requires access to a DCE server. The DCE server installation can be on the same host as the Policy Director system or can be located on a remote system. Use HP DCE 1.7.1 when running DCE servers on the same HP-UX system as the Policy Director servers.When using a remote DCE server installation, Policy Director on HP-UX requires only the HP DCE 1.7.1 Client to be installed locally.Refer to the HP DCE product documentation for installation and configuration information.

� If you are installing Policy Director into an existing Policy Director secure domain, Policy Director requires only a HP DCE Client installation.

External Software Requirements


3.6.2 User RegistryPolicy Director can use either an LDAP User Registry or a DCE User Registry. You are prompted to select the user registry type during Policy Director installation.

If you plan to use an LDAP User Registry, you must install an LDAP client and configure an LDAP server before installing Policy Director.

If you plan to use a DCE User Registry, you can skip the chapter on installing and configuring LDAP.

Policy Director supports the following user registry technologies:� LDAP user registry� Lotus Domino user registry� DCE user registry

The LDAP user registry is most widely used. Policy Director supports the following LDAP products:� Tivoli SecureWay Directory Version 3.2� Netscape LDAP 4.1 and above

The LDAP user registry is installed during LDAP server installation. Policy Director requires that the host system be configured into the LDAP schema. The host system must have at least an LDAP client installed and configured for use with an LDAP server. The LDAP server is not required to be installed on a system that runs Policy Director.


3–10 Version 3.7

3.7 Creating a New Secure Domain The Policy Director security environment is called a secure domain. A secure domain is a secure computing environment in which Policy Director enforces your security policies for authentication, authorization, and access control.

Each time you install Policy Director onto a HP-UX system, you complete one of the following tasks:� Creating a new secure domain� Adding a Policy Director server system into an existing secure domain� Adding a Policy Director runtime environment into an existing secure

domain.

Each of these tasks applies to the Policy Director WebSEAL and NetSEAL server applications. The installation requirements and the configuration procedures differ for each of the tasks. The following sections describe the software requirements for each task.

The first system in a new Policy Director secure domain has several unique software requirements.

The first system must contain the Policy Director Management Server. Each secure domain has only one Management Server. This server is key to the processing of access control, authentication, and authorization requests. The Management Server is packaged as one pkgadd package, PDMgr.

The Management Server requires that the local host system have a DCE infrastructure installed. This infrastructure can consist of a DCE client or it can consist of DCE servers. If a DCE client is installed, it must be configured into an existing DCE cell, which contains the DCE servers on other systems within the cell.

The Management Server access user information from a user registry. A DCE User Registry is created when DCE servers are established. This requirement is satisfied when either the DCE servers are installed on the local host or a DCE client is installed on the local host and configured into an existing DCE cell.

The Management Server also relies on Policy Director libraries and utilities that are distributed in the Policy Director Runtime. The Policy Director Runtime is the swinstall package PDRTE.

Creating a New Secure Domain


The minimum software required for the HP-UX system that will host the first Policy Director installation that creates a new secure domain is: � Policy Director Runtime Environment� Policy Director Management Server� HP DCE 1.7.1 Client

Figure 3-2: The minimum software required to create a new Policy Director secure domain.

In real-world deployments, you typically install more software on the first Policy Director system. The additional software usually consists of one or more of the following:� A graphical user interface for managing Policy Director security (Policy

Director Management Console).� A different type of user registry, such as LDAP or Domino.� An application that has been enabled to use Policy Director security. For

example, Policy Director WebSEAL.

Policy Director Management Server

HP-UX Server

Policy Director Runtime Environment

HP DCE 1.7.1

HP-UX 11.0


3–12 Version 3.7

3.7.1 A Typical Policy Director New Secure Domain InstallationA typical configuration for a host system that is configured to create a new Policy Director new secure domain could look as follows:

Figure 3-3: A typical HP-UX system configuration for a new Policy Director secure domain.

The above example illustrates the software needed to support an LDAP user registry, and includes the Policy Director WebSEAL application.

Policy Director WebSEAL

HP-UX Server

Policy Director Management Server

Policy Director Runtime Environment

IBM SecureWay Directory 3.2 Client

HP DCE 1.7.1

HP-UX 11.0

Adding a Policy Director Server System to a Secure Domain


3.8 Adding a Policy Director Server System to a Secure DomainPolicy Director is designed to scale effectively to support large, distributed computing environments. To maintain good performance, Policy Director provides an Authorization Server to off load access control and authorization decisions from the Management Server.

The Authorization Server is distributed on HP-UX as the swinstall package PDAcld.

The Authorization Server requires the host system to be a member of the same DCE cell as the Policy Director Management Server. This means that the host system for the Authorization Server must have DCE installed. Typically this is a DCE client. In Policy Director Version 3.7, the Authorization Server has been enhanced to use SSL to communicate with the remote Management Server. Although the Authorization Server no longer uses DCE RPCs for these communications, it still uses other DCE services.

Note: Each Policy Director secure domain has only one copy of the Management Server. Do not install the Policy Director Management Server when adding a system to an existing secure domain.

Typical addition of a second system in order to create a separate Authorization Server requires the following software:

Figure 3-4: Adding a second server system to an existing Policy Director secure domain.

Policy Director Secure Domain

First HP-UX Server

Policy DirectorManagment Server

Policy Director Runtime

HP DCE Client 1.7.1

HP-UX 11.0

Second HP-UX Server

Policy DirectorAuthorization Server


HP DCE Client 1.7.1

HP-UX 11.0


3–14 Version 3.7

3.9 Adding a Policy Director Runtime System to a Secure DomainPolicy Director Base, Version 3.7, distributes the Policy Director runtime libraries and utilities in a separate swinstall package, called PDRTE. You can add HP-UX systems into the Policy Director secure domain by installing and configuring this package. You do not need to install any of the Policy Director servers in order to add the HP-UX system to the secure domain.

This configuration is useful when preparing a system to support one of the Policy Director applications, such as WebSEAL or NetSEAL, or to support third-party application that have been built with the Policy Director Authorization ADK. These applications can make use of Policy Director servers that reside on other systems within the secure domain.

3.9.1 Using Policy Director without DCEThe Policy Director Runtime, when installed without any of the Policy Director servers, does not require the local host to be configured into the DCE cell. This means that you can easily add multiple hosts into the Policy Director secure domain without having DCE administrative privileges or knowing the DCE cell configuration. This enables you to easily add additional copies of applications.

For example, you can add an application developed with the Policy Director Authorization API to a Policy Director secure domain as illustrated:

Figure 3-5: Policy Director Runtime system without DCE, configured into a Policy Director secure domain.

Policy Director Secure Domain


Policy DirectorRuntime System

Application enabled forPolicy Director

IBM SecureWay Directory 3.2 LDAP Client

HP-UX 11.0

Policy Director Server

Policy DirectorManagment Server


IBM SecureWay Directory 3.2 LDAP Client

HP DCE Client 1.7.1

HP-UX 11.0

Installing a Policy Director Development Environment


3.10 Installing a Policy Director Development Environment You can create a development environment for adding Policy Director security capability to third-party application by installing the Policy Director Authorization Application Development Kit.

The Authorization Application Development Kit requires the Policy Director Runtime Environment to be installed.

The Policy Director Development environment usually contains an Authorization Server. The Authorization Server can be on the same system as the third-party application, or can be on a remote system.


3–16 Version 3.7


4Configuring IBM LDAP

Policy Director supports the IBM SecureWay Directory LDAP user registry. This chapter explains how to add information about Policy Director to the IBM SecureWay Directory LDAP Directory Information Tree.

� If your secure domain does not use an LDAP user registry, skip this chapter.

� If your secure domain uses a Netscape LDAP server, see Chapter 5, “Configuring a Netscape LDAP Server.

� If you are updating a Policy Director 3.6 installation that uses an IBM SecureWay Directory LDAP server, you need only complete the instructions in Section 4.3.2 “Upgrading Policy Director Security Schema”.

Before you install the Policy Director servers, you must install and configure both an LDAP server and an LDAP client. You must perform the basic LDAP configuration, as described in the IBM SecureWay Directory Installation and Configuration Guide, Version 3.2.

This chapter provides relevant notes about the IBM SecureWay Directory LDAP server and client installations, and then provides instructions for adding Policy Director information to the LDAP configuration.

Complete the instructions in the following sections.

� 4.1 Installing IBM SecureWay Directory

� 4.2 Adding Policy Director Suffixes

� 4.3 Installing or Upgrading Policy Director Security Schema

� 4.4 Configuring LDAP Access Control on ACLs

Chapter 4: Configuring IBM LDAP

4–2 Version 3.7

4.1 Installing IBM SecureWay Directory

Policy Director requires both an IBM SecureWay Directory LDAP server and an IBM SecureWay Directory LDAP client to be installed and configured. The LDAP Server does not have to be on the same system as the Policy Director servers.

Complete the instructions in the following sections:

� Installing an IBM LDAP Server (Section 4.1.1)

� Optimizing IBM LDAP Server Performance (Section 4.1.2)

� Installing IBM LDAP Server Patches (Section 4.1.3)

� Installing an IBM LDAP Client (Section 4.1.4)

� Installing an IBM LDAP Client Patch (Section 4.1.5)

4.1.1 Installing an IBM LDAP Server

The IBM SecureWay Directory Version 3.2 LDAP server is supported on the following platforms:

� AIX

� Solaris

� Windows

If you will be installing Policy Director on an HP-UX system, and want to use an IBM SecureWay Directory Version 3.2 LDAP server, you must install the server on one of the supported platforms.

During the installation of IBM SecureWay Directory LDAP Server Version 3.2, choose to install SecureWay Directory and Client SDK.

If you are installing the LDAP server on the same system that will run Policy Director WebSEAL, ensure that the system’s Web server and WebSEAL do not use the same port. Policy Director WebSEAL uses port 80 by default. Configure the system’s Web server to use another port, such as 8080.

For more detailed information about the installation of IBM SecureWay Directory LDAP, see the IBM SecureWay Directory Installation and Configuration, Version 3.2, documentation.

Note: LDAP permits passwords to be stored as clear text, which could pose a security risk. See your LDAP documentation for instructions on setting user password attributes to the appropriate encryption level.

Installing IBM SecureWay Directory


4.1.2 Optimizing IBM LDAP Server Performance

LDAP 3.2 has a function called Change Log which is used to record all updates to LDAP. Other applications can then query LDAP to track these updates.

These changes are recorded in a separate DB2 database (not in the database which contains the LDAP server Directory Information Tree).

If Change Log is enabled, every update to LDAP results in an entry being created in this second database. This has a performance impact.

Additionally, another LDAP suffix gets created called CN=CHANGELOG. This suffix is reported by LDAP if the root DSE is queried—an action Policy Director performs to learn what suffixes exist on that server.

Policy Director tries to search for this suffix when, for example, it looks up user and group information. This causes another performance penalty.

By default, Change Log is enabled and the second database is created if the LDAP GUI configuration tool is used (ldapxcfg). You have to disable the option when presented with the panel asking which type of DB2 Database to create (UTF-8 or local codepage).

If the command-line LDAP configuration tool is used (ldapcfg), the default is not to create the second database for Change Log and the problem does not occur.

To avoid the extra database and the performance impact, do not configure Change Log for LDAP.

If you use the LDAP GUI configuration interface, uncheck the option for "Create a database for Change Log support" when you are asked to choose a DB2 database type.

If you use the command-line LDAP configuration tool, do not specify the “–g” option (which enables Change Log).


4–4 Version 3.7

4.1.3 Installing IBM LDAP Server Patches

The Policy Director Base CD contains patches for the IBM SecureWay Directory LDAP client.

The libback-rdbm patch (one for each LDAP server platform) is for fixing an LDAP server large-group performance problem.

The libslapi patch (one for each LDAP server platform) is for fixing an LDAP server functional problem.

1. Back up the following files:

2. Copy the appropriate files from the Policy Director Base CD to the destination file location:

OS File Name

AIX /usr/ldap/lib/libmback-rdbm.a/usr/ldap/lib/libslapi.a

Solaris /opt/IBMldapc/lib/libback-rdbm.so/opt/IBMldaps/lib/libslapi.so

Windows

<install drive>:<install directory root>/IBM/LDAP/bin/libback-rdbm.dll<install drive>:<install directory root>/IBM/LDAP/bin/libslapi.dll

OS Source File Destination File Location

AIX /Patch/libmback-rdbm.a/Patch/libslapi.a

/usr/ldap/lib/libmback-rdbm.a/usr/ldap/lib/libslapi.a

Solaris /Patch/libback-rdbm.so/Patch/libslapi.so

/opt/IBMldapc/lib/libback-rdbm.so/opt/IBMldaps/lib/libslapi.so

Windows

\Patch\libback-rdbm.dll

<install drive>:<install directory root>/IBM/LDAP/bin/libback-rdbm.dll

\Patch\libslapi.dll

<install drive>:<install directory root>/IBM/LDAP/bin/libslapi.dll

Installing IBM SecureWay Directory


4.1.4 Installing an IBM LDAP Client

Before installing the client, you must have an LDAP server already installed.

If you have not yet installed the LDAP client on the system that will host Policy Director, install it now.

� Install IBM SecureWay Directory LDAP Client SDK Version 3.2.

� When installing the LDAP Client, choose to install SecureWay Client SDK.

The LDAP Client must be installed on each system that will run Policy Director.

For more information about the installation and basic configuration of LDAP, see the IBM SecureWay Directory Installation and Configuration, Version 3.2, documentation.


4–6 Version 3.7

4.1.5 Installing an IBM LDAP Client Patch

The Policy Director Base CD contains a patch for the IBM SecureWay Directory Version 3.2 LDAP client. Install this patch after you install the IBM SecureWay Directory LDAP client.

1. Back up the following file:

2. Copy the appropriate file from the Policy Director Base CD to the destination file location:

OS File Name

AIX /usr/ldap/lib/libldap.a

Solaris /opt/IBMldapc/lib/libibmldap.so

Windows <install drive>:<install directory root>/IBM/LDAP/bin/ldap.dll

HP-UX /opt/adt/lib/libldap.sl

OS Source File Destination File Location

AIX /Patch/libldap.a /usr/ldap/lib/libldap.a

Solaris /Patch/libibmldap.so /opt/IBMldapc/lib/libibmldap.so

Windows \Patch\ldap.dll

<install drive>:<install directory root>/IBM/LDAP/bin/ldap.dll

HP-UX /Patch/libldap.sl /opt/adt/lib/libldap.sl

Adding Policy Director Suffixes


4.2 Adding Policy Director Suffixes

If you are updating a Policy Director 3.6 installation, do not use this section. Go to Section 4.3.2: “Upgrading Policy Director Security Schema”.

In the IBM SecureWay Directory DIT (Directory Information Tree), create a new suffix by completing the following steps:

1. Using a Web browser, access the IBM SecureWay Directory Server Web Administration tool at the following address:

http://<servername>:<port>/ldap/index.html

The default port number is 8080.

2. Log in through the Web interface as the LDAP administrator. Type the name of the LDAP administrator in the field User ID. For example, “cn=root”.

3. Enter the LDAP administrator password.

4. Click Logon.

The IBM SecureWay Directory Server Administration Web page appears.

5. In the left frame, click Settings > Suffixes.

The Suffixes frame appears.

6. Type a Suffix DN for your organization and country. For example:

o=tivoli,c=us

7. Click Update.

The Suffixes frame appears.

8. Type the following Suffix DN:

secAuthority=Default

9. Click Update.

The Suffixes frame appears. You new suffixes should appear in the Current server suffixes table. Next, restart the LDAP server.

10. Click Restart the server in the upper portion of the right frame.

The Restart Server page appears. The message The directory server is running appears after a few minutes. If the message fails to appear, go to the Services window and restart the LDAP server.

11. Exit the browser.


4–8 Version 3.7

4.3 Installing or Upgrading Policy Director Security Schema

If you are installing a new Policy Director secure domain, you must install Policy Director security schema information.

If you are updating an existing Policy Director Version 3.6 secure domain, you must upgrade the Policy Director security schema information.

Go to the appropriate section:

� Installing Policy Director Security Schema (Section 4.3.1)

� Upgrading Policy Director Security Schema (Section 4.3.2)

4.3.1 Installing Policy Director Security Schema

Note: If you are updating a Policy Director 3.6 installation, do not use this section. Go to Section 4.3.2: “Upgrading Policy Director Security Schema”.

An LDAP server supports a set of directory object and attribute types in which to store data. Objects are defined to allow a set of required attributes and a set of allowed attributes. Objects may be defined to be derived from other objects.

In this case, the derived object contains both the superclass object (the one from which it was derived) attributes as well as additional object-specific attributes. The complete set of defined object and attribute types supported by the LDAP server is referred to as the LDAP schema.

In addition to using the LDAP server to store its user and group information, Policy Director also stores its meta-data within the LDAP server. This allows Policy Director to maintain a consistent backing store and to take advantage of the security support of the LDAP server to protect its data from unwanted interrogation or corruption.

Because Policy Director stores this meta-data within the LDAP server, the LDAP server must be updated to support the set of object and attribute type definitions needed by Policy Director. This is done by updating the LDAP server with the Policy Director schema. This needs to be done only once, to update the LDAP server to recognize the new schema definition.

After the LDAP server has been installed and the IBM SecureWay Directory client has been installed on the Policy Director server machines, the schema can be updated. The schema file is distributed as a plain text file on the Policy Director Base CD. The location on the CD of the Policy Director schema file for use with IBM SecureWay Directory is shown in the table below:

Installing or Upgrading Policy Director Security Schema


To use the schema definition file to update the schema, run the following command from any machine where the IBM SecureWay Directory client is installed:

1. Insert the Tivoli SecureWay Policy Director Base Version 3.7 CD into your CD-ROM drive.

You can do this on either the LDAP server or LDAP client machine. These instructions assume the LDAP client.

2. Copy the security schema file to the LDAP client’s bin directory:

# cp /<mount-point>/Schema/secschema.def /opt/IBMldapc/bin

3. Use the ldapmodify utility to add the secschema.def contents to the DIT:

# ldapmodify -h <hostname> -p 389 -D cn=root -w <password> \-c -f secschema.def

The following table describes each of the parameters to ldapmodify:

The ldapmodify command processes the secschema.def file and updates the IBM SecureWay Directory Server with the Policy Director schema definitions. The command must be executed with appropriate authority to update the schema on the LDAP server. This is specified with the -D cn=root and -w password parameters in the examples above.

Platform Policy Director Security Schema File

Solaris, AIX, HP-UX /Schema/secschema.def

Windows \Schema\secschema.def

Parameter Description

hostname The name of the host where the LDAP server is running.

389 The port used by the LDAP server.

cn=root The name of the Directory Manager for the server.

password The password for the Directory Manager

/Schema/secschema.def The Policy Director LDAP schema file.

x: The drive letter of your Windows CD-ROM drive.


4–10 Version 3.7

4.3.2 Upgrading Policy Director Security Schema

Note: If you are installing a new Policy Director Version 3.7 secure domain, do not use this section. Go to Section 4.3.1: “Installing Policy Director Security Schema”

Policy Director 3.7 provides an LDAP schema file that contains only the objects and attributes that have changed since Policy Director 3.6. When you are updating a Policy Director 3.6 installation, you can use this file to update the IBM SecureWay Directory LDAP Directory Information Tree.

The schema file is distributed as a plain text file on the Policy Director Base CD. The location on the CD of the Policy Director schema file for use with IBM SecureWay Directory LDAP is shown in the table below:

To use the upgrade schema file, complete the following instructions:



2. Copy the upgrade schema file to the IBM SecureWay Director LDAP client’s bin directory.

# cp /<mnt>/Schema/upgrade3.6_ibm_schema.def /opt/IBMldapc/bin

3. Use the ldapmodify utility to add the upgrade schema file to the DIT:# ldapmodify -h <host> -p 389 -D cn=root -w <password> \-c -f upgrade3.6_ibm_schema.def

4. Log in through the Web interface as the LDAP administrator. Type the name of the LDAP administrator in the field User ID. For example, “cn=root”.

5. Enter the LDAP administrator password.

6. Click Logon. The IBM SecureWay Directory Server Administration Web page appears. Restart the LDAP server.


Solaris, AIX, HP-UX /Schema/upgrade3.6_ibm_schema.def

Windows \Schema\upgrade3.6_ibm_schema.def

Configuring LDAP Access Control on ACLs


4.4 Configuring LDAP Access Control on ACLs

Note: If you are updating a Policy Director 3.6 installation, do not use this section. Go to Section 4.3.2: “Upgrading Policy Director Security Schema”.

To complete the integration of Policy Director security with the LDAP user registry, update the LDAP ACLs that control the user registry by completing the instructions in the following sections.

� Adding the LDAP Server Entry (Section 4.4.1)

� Adding the Organization Entry (Section 4.4.2)

� Adding the Policy Director Group to LDAP ACLs (Section 4.4.3)


4–12 Version 3.7

4.4.1 Adding the LDAP Server Entry

1. Start the Directory Management Tool.

� On Solaris, AIX, or HP-UX type:

# /opt/IBMldapc/bin/dmt

� On Windows NT, select Start > Programs > IBM SecureWay Directory > Directory Management Tool

The following warnings might appear:

Warning: Entry o=tivoli,c=us does not contain any data.

Warning: Entry secAuthority=default does not containany data.

You can safely ignore these warnings. Click OK to clear the warning dialog boxes.

The Directory Management Tool page appears.

2. Click Add server at the bottom of the left hand frame.

The Add Directory Server window appears.

3. Enter values for the following fields:

4. Click OK.

The Directory Management Tool page appears.

5. Verify the server name in the upper part of the left frame. For example:

Ldap://ibm007.ibm.com:389

6. Continue to Section 4.4.2: “Adding the Organization Entry”

Field Value Comment

Server Name ldap://<hostname> For example, ibm007.ibm.com

Port 389 389 is the default port

User DN cn=root DN of the LDAP administrator

User Password abc123 Password of the LDAP administrator

Configuring LDAP Access Control on ACLs


4.4.2 Adding the Organization Entry

Continuing from the previous section, the Directory Management Tool should be running.

1. From the tree structure on the left, click the node Directory Tree/Browse Tree.

The following warnings might appear:

Warning: Entry o=tivoli,c=us does not contain any data.

Warning: Entry secAuthority=default does not containany data.

You can safely ignore these warnings. Click OK to clear the warning dialog boxes.

2. Select cn=localhost.

3. Click Add in the upper part of the right frame.

The Add an LDAP Entry dialog box appears.

4. Enter the following values:

5. Select Organization and click OK.

The entry page for Organization appears within the Add an LDAP User dialog box.

6. Enter the organization name in the Attributes section at the o: label. For example: tivoli.

In this example, Organization is tivoli because this value must match the previously entered RDN value of o=tivoli.

7. Click Add.

The Browse Directory Tree page appears.

8. Click the node Directory Tree/Refresh Tree in the left frame.

The entry o=tivoli,c=us appears.

9. Continue to Section 4.4.3: “Adding the Policy Director Group to LDAP ACLs”.

Label Value

Parent DN c=us

Entry RDN o=tivoli


4–14 Version 3.7

4.4.3 Adding the Policy Director Group to LDAP ACLs

Continuing from the previous section, you should see the Browse Directory Tree page of the Directory Management Tool. This page displays the entry you just added.

1. Select o=tivoli,c=us.

2. Click ACL in the upper portion of the right frame.

The Edit an LDAP ACL page appears.

3. Select Do not inherit from ACL source.

4. Select Descendant directory entries inherit from this entry.

5. Select the Owners tab.

6. Select the Group entry in the Type section of the current frame.

7. In field labeled Distinguished Name (DN), type:

cn=SecurityGroup,secAuthority=Default

8. Click Add.

9. Click OK.

The Browse Directory Tree page appears.

10. Click Exit to close the Directory Management Tool.

Configuration of the Policy Directory entries for LDAP organization and groups is now complete.

IBM SecureWay Directory can optionally be configured to support SSL access between LDAP servers and clients. For more information, see Chapter 6, Configuring SSL Access for IBM LDAP.


5Configuring a Netscape LDAP Server

Policy Director supports the Netscape LDAP user registry. This chapter explains how to add information about Policy Director to the Netscape LDAP Directory Information Tree (DIT).

� If your secure domain does not use an LDAP user registry, skip this chapter.

� If your secure domain uses a IBM LDAP server, see Chapter 4, ”Configuring IBM LDAP”.

� If you are updating a Policy Director 3.6 installation that uses a Netscape LDAP server, you need only complete the instructions in Section 5.3.2: “Updating Policy Director Security Schema”.

Before you install the Policy Director servers, you must install and configure both the LDAP server and an LDAP client.

Policy Director supports the use of an IBM SecureWay Directory LDAP Client with a Netscape LDAP server.

This chapter provides relevant notes about the Netscape LDAP server and IBM SecureWay Directory client installations, and then provides instructions for adding Policy Director information to the LDAP configuration.

Complete the instructions in the following sections.

� 5.1 Installing a Netscape Server and IBM Client

� 5.2 Adding Suffixes for Netscape Directory Server

� 5.3 Installing or Updating Policy Director Security Schema

� 5.4 Configuring SSL Access for Netscape Directory Server

Chapter 5: Configuring a Netscape LDAP Server

5–2 Version 3.7

5.1 Installing a Netscape Server and IBM Client

Policy Director requires both an Netscape LDAP server and an IBM SecureWay Directory LDAP client to be installed and configured before you install Policy Director. See the following sections:

� Installing a Netscape LDAP Server (Section 5.1.1)

� Installing an LDAP Client (Section 5.1.2)

5.1.1 Installing a Netscape LDAP Server

Before adding Policy Director information to the LDAP Directory Information Tree, you must complete the basic Netscape LDAP server installation and configuration as described in the Netscape documentation.

If you are installing the LDAP server on the same system that will run Policy Director WebSEAL, ensure that the system’s Web server and WebSEAL do not use the same port. Policy Director WebSEAL uses port 80 by default. Configure the system’s Web server to use another port, such as 8080.

5.1.2 Installing an LDAP Client

Policy Director does not support the Netscape LDAP client. Policy Director supports the IBM SecureWay Directory LDAP client. You can use the IBM SecureWay Directory LDAP client with the Netscape LDAP server. You must perform the basic LDAP configuration, as described in the IBM SecureWay Directory Installation and Configuration Guide, Version 3.2.

Before installing the client, you must have an LDAP server already installed.

If you have not yet installed the LDAP client on the system that will host Policy Director, install it now.

� Install IBM SecureWay Directory LDAP Client SDK Version 3.2.

� When installing the LDAP Client, choose to install SecureWay Client SDK.

The LDAP Client must be installed on each system that will run Policy Director.

Adding Suffixes for Netscape Directory Server


5.2 Adding Suffixes for Netscape Directory Server

Data is stored within the Netscape LDAP server in a hierarchical tree structure referred to as the Directory Information Tree (DIT). The top of the tree is called a suffix. An LDAP server can contain multiple suffixes.

Policy Director maintains some of its meta-data within a specific suffix within the LDAP server. This Policy Director suffix must be created once, when the LDAP server is first installed.

Note: If you are updating a Policy Director 3.6 installation, do not use this section. Go to Section 5.3.2: “Updating Policy Director Security Schema”.

To create the Policy Director suffix:

1. Start the Netscape Directory Console. On Windows NT, start the Console by selecting: Start > Programs > Netscape Server Products >Netscape Console

2. Enter the User ID for the LDAP administrator.

3. Enter the Password.

4. Enter the Administration URL.

5. Select the Domain to be used by Policy Director.

6. Expand the server name.

7. Expand Server Group

8. Select the entry labeled Directory Server.

Configuration information about Netscape Server is presented.

9. Click the Open button.

The Netscape Directory Server is accessed.

10. Click the Configuration tab.

11. In the left panel displayed, select Database.

12. Select the Settings tab.

The lower portion of the displayed panel shows the set of currently configured suffixes.


5–4 Version 3.7

13. Click the Add button.

A new blank line is inserted.

14. Type the following suffix into the new blank line:

secAuthority=Default

15. Click the Save button

5.2.1 Adding a Suffix for GSO

Policy Director can also utilize IBM Global Sign-On technology to allow single sign-on to third-party junctioned Web Servers, but you must enable this capability when the junctioned Web Servers are configured. The IBM Global Sign-On technology also stores its information into the LDAP server.

When Policy Director is installed and initially configured, the administrators is given the opportunity to indicate where in the LDAP DIT the Global Sign-On meta-data should be stored. The Global Sign-On meta-data can be stored anywhere in the DIT that the administrator chooses. However, the Global Sign-On information should not be stored in the secAuthority=Default suffix that you created previously. You should either plan to store the Global Sign-On information into an existing location in the DIT or create a new branch in the DIT for the Global Sign-On information.

If desired, the administrator may also create an additional new suffix in which to store the Global Sign-On information. If you choose to store the Global Sign-On information in a new suffix, you should create the suffix before Policy Director is installed. Then, when Policy Director is installed and you are requested to enter the location in which to store the Global Sign-On information, you may provide the Distinguished Name of the suffix you created.

To create the Policy Director suffix:






Adding Suffixes for Netscape Directory Server









11. In the left panel displayed, select Database.

12. Select the Settings tab.

The lower portion of the displayed panel shows the set of currently configured suffixes.

13. Click the Add button.

A new blank line is inserted.

14. Add a suffix for your Policy Director users and Global Sign-On (GSO) data. For example:

o=tivoli,c=us

This step creates suffixes for your GSO data and for your users and groups.These suffixes are created with the LDAP Web Administration tool.

15. Click the Save button.

16. Restart the Netscape LDAP server.


5–6 Version 3.7

5.3 Installing or Updating Policy Director Security Schema

If you are installing a new Policy Director secure domain, you must install Policy Director security schema information.

If you are updating an existing Policy Director Version 3.6 secure domain, you must update the Policy Director security schema information.

Go to the appropriate section:

� Installing Policy Director Security Schema (Section 5.3.1)

� Updating Policy Director Security Schema (Section 5.3.2)

5.3.1 Installing Policy Director Security Schema

Note: If you are updating a Policy Director 3.6 installation, do not use this section. Go to Section 5.3.2: “Updating Policy Director Security Schema”.

An LDAP server supports a set of directory object and attribute types in which to store data. Objects are defined to allow a set of required attributes and a set of allowed attributes. Objects may be defined to be derived from other objects.

In this case, the derived object contains both the superclass object (the one from which it was derived) attributes as well as additional object-specific attributes. The complete set of defined object and attribute types supported by the LDAP server is referred to as the LDAP schema.

In addition to using the LDAP server to store its user and group information, Policy Director also stores its meta-data within the LDAP server. This allows Policy Director to maintain a consistent backing store and to take advantage of the security support of the LDAP server to protect its data from unwanted interrogation or corruption.

Because Policy Director stores this meta-data within the LDAP server, the LDAP server must be updated to support the set of object and attribute type definitions needed by Policy Director. This is done by updating the LDAP server with the Policy Director schema. This needs to be done only once, to update the LDAP server to recognize the new schema definition.

Installing or Updating Policy Director Security Schema


After the LDAP server has been installed and the IBM SecureWay Directory client has been installed on the Policy Director server machines, the schema can be updated. The following schema file is distributed on the Policy Director Base CD, for use with Netscape server:

To use the schema definition file to update the schema, run the following command from any machine where the IBM SecureWay Directory client is installed:



2. Copy the security schema file to the LDAP client’s bin directory.

# cp /<mount-point>/Schema/nsschema.def /opt/IBMldapc/bin

3. Use the ldapmodify utility, as illustrated below, to add the nsschema.def contents to the DIT.

ldapmodify -h <hostname> -p 389 -D "cn=Directory Manager" -wpassword -c -f nsschema.def


SolarisAIXHP-UX

/Schema/nsschema.def

Windows \Schema\nsschema.def


5–8 Version 3.7

The following table describes each of the parameters to ldapmodify:

The ldapmodify command processes the nsschema.def file and updates the Netscape Directory Server with the needed Policy Director schema definitions. Because the schema is being updated for the LDAP server, the command must be executed with appropriate authority to update the schema. This is specified with the -D cn=Directory Manager and -w password parameters in the examples above.

When you have created the required Policy Director suffix and the schema is successfully updated, the Netscape Directory Server is ready to support Policy Director.

Parameter Description

hostname The name of the host where the LDAP server is running.

389 The port used by the LDAP server.

cn=Directory Manager The name of the Directory Manager for the server.

password The password for the Directory Manager

nsschema.def The Policy Director LDAP schema file.

Installing or Updating Policy Director Security Schema


5.3.2 Updating Policy Director Security Schema

Note: If you are installing a new Policy Director 3.7 installation, do not use this upgrade section. Go to Section 5.3: “Installing or Updating Policy Director Security Schema”.

Policy Director 3.7 provides an LDAP schema file that contains only the object type definitions and attribute type definitions that have changed since Policy Director 3.6. When you are updating a Policy Director 3.6 installation, you can use this file to update the Netscape LDAP Directory Information Tree.

The schema file is distributed as a plain text file on the Policy Director Base CD. The location on the CD of the Policy Director schema file for use with Netscape LDAP is shown in the table below:

To use the update schema file, complete the following instructions:



2. Copy the update schema file to the LDAP client’s bin directory.

# cp /<mount-point>/Schema/upgrade3.6_netscape_schema.def/opt/IBMldapc/bin

3. Use the ldapmodify utility, as illustrated below, to add the update schema file contents to the DIT.

ldapmodify -h <hostname> -p 389 -D "cn=Directory Manager"-wpassword -c -f upgrade3.6_netscape_schema.def


SolarisAIXHP-UX

/Schema/upgrade3.6_netscape_schema.def

Windows \Schema\upgrade3.6_netscape_schema.def


5–10 Version 3.7

5.4 Configuring SSL Access for Netscape Directory Server

Secure Socket Layer (SSL) allows the data which is transmitted between the Policy Director services and the Netscape Directory Server, to be encrypted to provide data privacy and integrity. It is recommended that administrators enable SSL to protect information such as user passwords and private data. However, SSL is not required for Policy Director to operate.

If SSL is not required in your Policy Director environment, skip this section.

If SSL access is required, continue with this section.

This procedure only needs to be done the first time SSL communication is set up between the Netscape Directory Server and the Policy Director services (LDAP clients). To enable SSL communications, both the Netscape Directory Server and the Policy Director services must be configured.

If the Netscape Directory Server has already been configured for SSL access, you can skip this section.

For complete information on enabling SSL access on Netscape Directory Server, see the Netscape Directory Server documentation.


� Obtaining a Server Certificate (Section 5.4.1)

� Installing the Server Certificate (Section 5.4.2)

� Enabling SSL Access (Section 5.4.3)

Configuring SSL Access for Netscape Directory Server


5.4.1 Obtaining a Server Certificate

To enable SSL support, the Netscape Directory Server requires a Certificate that proves its identity to client systems. The server sends the certificate to the client to enable the client to authenticate with the server. This certificate is called a Server-Cert.

Use the Netscape Directory Console and the Certificate Setup Wizard to establish the Server-Cert.













11. Click the Encryption tab.

12. Verify that the Enable SSL check box is not checked.

Note: SSL should not be enabled until the Server-Cert has been requested and installed.

13. Click the Certificate Setup Wizard button.

The Wizard will lead you through the process to request and install a Server-Cert.

14. Click Next.


5–12 Version 3.7

15. Select a Token (Cryptographic Device).

Note: Netscape refers to the private key portion of a public key/private key pair as a token.

You are prompted to specify how to store the private key (token).

16. Select internal (software).

The Netscape Directory Server encrypts the private key (token) and maintains it internally.

Note: If the Netscape Directory Server system has a token card device, you can optionally store the private key (token) on the token card device. For more information see the Netscape documentation.

A prompt appears, asking Is the server certificate already requested and ready to install?

17. Click No.

18. Click Next to continue.

The Wizard now presents an explanation about how to generate a request.

19. Click Next.

20. Fill out the request for a New Certificate.

21. Provide the requested information about your server and organization.

22. Choose the Certificate Authority to use, or specify a different Certificate Authority.

23. Type in a Trust Database Password.

Note: Remember this password. You must use when you install the certificate that you are requesting from the Certificate Authority

24. Send the certificate request to the Certificate Authority.



5.4.2 Installing the Server Certificate

After you have received the certificate from the Certificate Authority, install it by completing the following steps:













11. Click the Encryption tab.

12. Verify that the Enable SSL check box is not checked.

A prompt appears, asking Is the server certificate already requested and ready to install?

13. Click Yes.

14. Click Next.

15. Click Next on the next information panel.

A prompt appears asking What to Install Certificate for?

16. Select This Server.

A prompt appears asking you to enter the Trust Database Password.


5–14 Version 3.7

17. Enter the Trust Database Password.

Note: This is the password you specified in Section 5.4.1: “Obtaining a Server Certificate”.

You are prompted how to install the certificate.

18. Either enter the certificate file name, or cut and paste the certificate information.

19. Click Next.

The Wizard displays information about the certificate.

20. Review the information and verify that it is correct.

21. Click the button to install the certificate.

22. Exit the Wizard after the certificate has been installed.

23. Continue to Section 5.4.3: “Enabling SSL Access”.



5.4.3 Enabling SSL Access

When you have exited the Certificate Setup Wizard, you are returned to the Encryption tab on the Netscape Directory Console.

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 the Netscape Directory Server to effect the changes

Note: You have to type the Trust Database Password each time the server is started

SSL is now enabled on the Netscape LDAP server. Next, you need to enable SSL on the Policy Director systems that will function as clients to the Netscape LDAP server. See Chapter 6, ”Configuring SSL Access for IBM LDAP”.


5–16 Version 3.7


6Configuring SSL Access for IBM LDAP

You can optionally configure Secure Socket Layer (SSL) as the communications protocol used between IBM SecureWay Directory LDAP servers and IBM SecureWay Directory LDAP clients. This chapter provides instructions on how to complete this configuration.

� If you are not using SSL communication between IBM SecureWay Directory LDAP servers and clients, skip this chapter.

� You must install and configure the IBM SecureWay Directory LDAP server and clients before using this chapter. For more information, see Chapter 4, ”Configuring IBM LDAP”.

Topic Index:

� 6.1 Overview of LDAP SSL Configuration

� 6.2 Configuring the LDAP Server for SSL Access

� 6.3 Configuring the LDAP Client for SSL Access

� 6.4 Configuring LDAP Server and Client Authentication

Chapter 6: Configuring SSL Access for IBM LDAP

6–2 Version 3.7

6.1 Overview of LDAP SSL Configuration

We recommend the use of SSL communication between LDAP servers and LDAP clients that support Policy Director. This protocol provides secure, encrypted communications between each server and client. Policy Director uses these communications channels as part of the process for making authentication and authorization decisions.

The configuration of SSL between the LDAP server and LDAP clients does not involve any configuration specific to Policy Director. The SSL configuration is an option supported by IBM SecureWay Directory separately from any Policy Director support.

Configuration of SSL must be done precisely in order to ensure secure communications channels. The IBM SecureWay Directory documentation provides SSL configuration instructions. However, because this security is important to Policy Director deployments, this chapter contains information that augments the IBM SecureWay Directory documentation.

The SSL configuration tasks can be divided into tasks that are accomplished on the LDAP server, and tasks that are accomplished on the LDAP client. You must first configure SSL on the LDAP server, and then configure SSL on the LDAP client.

During SSL configuration, you are asked to choose between one of two types of authentication:

� Server Authentication

� Server and Client Authentication

The Server Authentication mode is described in the main Server and Client sections of this chapter. The Server and Client Authentication mode is described in a separate section. This authentication mode involves setting up a client-side certificate. These additional steps are not needed when configuring Server Authentication only.

To configure SSL communication between your LDAP server and client, complete the instructions in the following sections:

� Configuring the LDAP Server for SSL Access (Section 6.2)

� Configuring the LDAP Client for SSL Access (Section 6.3)

If you choose to implement Server and Client Authentication, complete the instructions in the following section:

� Configuring LDAP Server and Client Authentication (Section 6.4)

Configuring the LDAP Server for SSL Access


6.2 Configuring the LDAP Server for SSL Access

You can enable the use of SSL to protect communications between the Policy Director servers and the LDAP server. This step only needs to be done the first time SSL communication is set up between the LDAP server and the LDAP client (Policy Director system).

If you previously enabled SSL access to the LDAP server during the LDAP server configuration, you will need to copy a client and server key ring pair to each additional Policy Director system that uses SSL access.

If SSL access is required by your LDAP server, use the IBM Global Security Toolkit to perform SSL key management. The IBM Global Security Kit (GSKit) Version 4.0 is installed during the installation of LDAP.

GSKit provides a graphical Key Management Tool called GSK4ikm.

Note: Complete instructions on how to use the Key Management tool can be found in the LDAP documentation.

To enable SSL access on the LDAP server, complete the instructions in the following sections:

� Creating the Key Database File and the Certificate (Section 6.2.1)

� Obtaining a Personal Certificate from a Certificate Authority (Section 6.2.2)

� Creating and Extracting a Self-signed Certificate (Section 6.2.3)

� Enabling SSL Access on the LDAP Server (Section 6.2.4)


6–4 Version 3.7

6.2.1 Creating the Key Database File and the Certificate

To enable SSL support on the LDAP sever, the server must have a certificate that identifies it and that it can use as a personal certificate. This personal certificate is the certificate that the server sends to the client to allow the client to authenticate the server. The certificates and the public and private key pair are stored in a key database file. A user normally acquires a signed certificate from a Certificate Authority (CA), such as VeriSign.

Alternatively, a user can use a self-signed certificate. If using a self-signed certificate, the machine on which the certificate is generated becomes the CA.

Use the GSKit’s Key Management Tool (gsk4ikm) to create the key database file and the certificate. To create the key database file and certificate (self-signed or signed), complete the following steps:

1. Ensure that the IBM Global Security Kit (GSKit) SSL Runtime Toolkit Version 4.0 and the Java-based Key Management Tool are installed on both the LDAP server and any LDAP clients that will be using SSL.

2. Start the Key Management tool (gsk4ikm).

3. Click:

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.

System Path

Windows C:\Program Files\IBM\GSK4\bin\GSK4ikm.exe

Solaris /opt/IBM/GSK4/bin/gsk4ikm

AIX /usr/lpp/ibm/gsk4/bin/gsk4ikm

HP-UX /usr/bin/gsk4/bin



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 wish the password to be masked and stored into a stash file, click Stash the password to a file.

A stash file can be used by some applications so that the application does not have to know the password to use the key database file. The stash file has the same 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 default signer certificates. These signer certificates are the default Certificate Authorities that are recognized.


6–6 Version 3.7

6.2.2 Obtaining a Personal Certificate from a Certificate Authority

If 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 the CA and then receive it after it has been completed.

If you plan to use a self-signed certificate, skip this section and go to Section 6.2.3: “Creating and Extracting a Self-signed Certificate”.

To request and receive a certificate, complete the following steps:

1. Use gsk4ikm to request a certificate from a CA 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. Fill in all the information to produce a request that can be sent to the Certificate Authority.

5. Click OK.

6. After the CA returns the certificate, you can install it into your key database file by clicking the Personal Certificates section, and then clicking Receive.

7. After you have the LDAP server’s certificate in the key database file, you can configure the LDAP server to enable SSL.

Go to Section 6.2.4: “Enabling SSL Access on the LDAP Server”.



6.2.3 Creating and Extracting a Self-signed Certificate

If you obtained a certificate from a known Certificate Authority, as described in the previous section Section 6.2.2: “Obtaining a Personal Certificate from a Certificate Authority”) skip this section and go Section 6.2.4: “Enabling SSL Access on the LDAP Server”.

To create a new self-signed certificate and store it into the key database file, complete the following steps:

1. Click:

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 machine name of the LDAP server.

3. Accept the defaults for the Version field, which is X509 V3, and for the Key Size field.

4. Either accept the default machine 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, GSKit queries if you want this key to be the default key in the database. You can accept one of them as the default. The default certificate is used at runtime when a label is not provided to select which certificate to use.

This completes the creation of the LDAP server’s personal certificate. It should appear in the Personal Certificates section of the key database file. Use the middle bar of the Key Management Tool to select between the types of certificates kept in the key database file.

The certificate should also appear in the Signer Certificates section of the key database file. When you are in the Signer Certificates section of the Key Database, verify that the new certificate is there.


6–8 Version 3.7

Next, you must extract your LDAP server’s certificate to a Base64-encoded ASCII data file.

9. Use gsk4ikm to extract your LDAP server’s certificate to a Base64-encoded ASCII data file.

This file will be used in Section 6.2.4: “Enabling SSL Access on the LDAP Server”.

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 .arm.

14. Type the location where you want to store the extracted certificate.

15. Click OK.

16. Copy this extracted certificate to the LDAP client machine.

You can now configure the LDAP server to enable SSL. Go to Section 6.2.4: “Enabling SSL Access on the LDAP Server”.



6.2.4 Enabling SSL Access on the LDAP Server

To configure the LDAP server to enable SSL:

1. Make sure that the LDAP server is installed and running if you will be using LDAP as the user registry.

2. Use the Web-based LDAP administration tool with the following URL:

http://servername/ldap/index.html

where servername is the name of the LDAP server machine.

3. Log on as the LDAP administrator (for example, cn=root) if you are not already logged on.

4. Click

Server > SSL

5. Click either SSL On, which enables SSL, or click SSL Only for the SSL status you want to set.

6. Choose one of the following authentication methods:

� Server Authentication

� Server and Client Authentication

For Server Authentication, the server sends its certificate to the client and the client authenticates the server.

For Server and Client Authentication, after the server has sent its certificate to the client and has been authenticated by the client, the server requests the client’s certificate. In this case, a certificate needs to be established for the client machine also.

If you chose Server and Client Authentication, you must establish the certificate for the client when enabling SSL access for the client in Section 6.4: “Configuring LDAP Server and Client Authentication”.

7. Type a port number, or accept the default port number of 636.

8. Type in the key database path and file name that you specified in Section 6.2.3: “Creating and Extracting a Self-signed Certificate”.

The key database file’s extension is .kdb.

9. Type the name in the Key Label field that you used to identify it when you stored the LDAP server’s certificate into the Key Database. For example, the label might be the machine name of the LDAP server.


6–10 Version 3.7

10. Enter the key database file password and confirm it. You can leave the password 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 LDAP server command line:

ldapsearch -h servername -Z -K keyfile -P key_pw -b "" -s baseobjectclass=*

The command options are as follows:

This command returns the LDAP base information, which includes the suffixes on the LDAP server.

The LDAP server SSL setup is now complete.

Next, set up the LDAP client for SSL access. Go to Section 6.3: “Configuring the LDAP Client for SSL Access”.

Option Description

servername The DNS host name of the LDAP server.

keyfile The fully qualified path name of the generated key ring.

key_pw The password of the generated key ring.

Configuring the LDAP Client for SSL Access


6.3 Configuring the LDAP Client for SSL Access

You must first set up the LDAP server for SSL access before you set up the LDAP client for SSL access. If you have not yet configured the LDAP server for SSL access, go to Section 6.2: “Configuring the LDAP Server for SSL Access”.

If SSL access is required by your LDAP client, use the IBM Global Security Toolkit to perform SSL key management. The IBM Global Security Kit (GSKit) Version 4.0 is installed during the installation of LDAP.

GSKit provides a graphical Key Management Tool called GSK4ikm.

Note: Complete instructions on how to use the Key Management tool can be found in the LDAP documentation.

To configure the LDAP client for SSL access to the LDAP server, complete the instructions in the following sections:

� Creating a Key Database File (Section 6.3.1)

� Adding a Signer Certificate (Section 6.3.2)

� Testing SSL Access (Section 6.3.3)


6–12 Version 3.7

6.3.1 Creating a Key Database File




3. Click:




6. Click OK.






System Path






10. Click OK.

This completes the creation of the key database file. There is set of default signer certificates. These signer certificates are the default Certificate Authorities that are recognized.

In order for the client to be able to authenticate the LDAP server, the client must recognize the Certificate Authority (signer) that created the LDAP server’s certificate. If the LDAP server is using a self-signed certificate, then the client must be enabled to recognize the machine that generated the LDAP server’s certificate as a trusted root (Certificate Authority).


6–14 Version 3.7

6.3.2 Adding a Signer Certificate

To add a signer certificate after the key database file has been created, complete the following steps:

1. Ensure that the certificate which was extracted from the key database file in Section 6.2.3: “Creating and Extracting a Self-signed Certificate” has been copied to the client machine. If it has not been copied, copy it now.

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 .arm.

6. Click OK.

7. Type a label for the signer certificate that you are adding. For example, you can use the machine name of the LDAP server for the label.

8. Click OK.

The self-signed certificate appears in the client’s Key Database as a signer certificate.

9. Highlight the newly added signer certificate, and click View/Edit.

10. Ensure that it is marked as a trusted root by making sure Set the certificate as a trust root is selected.

If the LDAP server’s certificate was generated by a regular Certificate Authority, be sure that the Certificate Authority is listed as a signer certificate and marked as a trusted root. If it is not, then add the Certificate Authority’s certificate as a signer certificate and indicate that it is a trusted root.

The client should now be able to establish an SSL session with the LDAP server.



6.3.3 Testing SSL Access

To test that SSL has been enabled, enter the following command from a command line on the LDAP client:

ldapsearch -h servername -Z -K client_keyfile -P key_pw -b "" -sbase objectclass=*


This command returns the LDAP base information, which includes the suffixes on the LDAP server.

During LDAP server configuration in Section 6.2: “Configuring the LDAP Server for SSL Access”, you chose an authentication method of either Server Authentication or Server and Client Authentication.

� If you chose Server Authentication, the SSL setup is now complete

� If you chose Server and Client Authentication, go to Section 6.4: “Configuring LDAP Server and Client Authentication”.

Option Description


client_keyfile The fully qualified path name of the generated client key ring.



6–16 Version 3.7

6.4 Configuring LDAP Server and Client Authentication

During the configuration of the LDAP server to enable SSL access, as described in Section 6.2.4: “Enabling SSL Access on the LDAP Server”, you were prompted to choose either Server Authentication 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 a certificate for the client machine. In this mode of authentication, the server will request the client’s certificate and use it to authenticate the client’s identity.

To establish a certificate for the client machine, complete the instructions in the following sections:

� Creating a Key Database File (Section 6.4.1)

� Obtaining a Personal Certificate from a Certificate Authority (Section 6.4.2)

� Creating and Extracting a Self-signed Certificate (Section 6.4.3)

� Adding a Signer Certificate (Section 6.4.4)

� Testing the SSL access (Section 6.4.5)

Configuring LDAP Server and Client Authentication


6.4.1 Creating a Key Database File




3. Click:




6. Click OK.






System Path





6–18 Version 3.7

10. Click OK.

This completes the creation of the key database file.There is set of default signer certificates. These signer certificates are the default Certificate Authorities that are recognized.



6.4.2 Obtaining a Personal Certificate from a Certificate Authority

If 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 the CA and then receive it after it has been completed.

If you plan to use a self-signed certificate, skip this section and go to Section 6.4.3: “Creating and Extracting a Self-signed Certificate”.

To request and receive a certificate, complete the following steps:

1. Use gsk4ikm to request a certificate from a CA 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. Fill in all the information to produce a request that can be sent to the Certificate Authority.

5. Click OK.

6. After the CA returns the certificate, you can install it into your key database file by clicking the Personal Certificates section, and then clicking Receive.

7. After you have the LDAP client’s certificate in the key database file, you can add the client certificate to the LDAP server.

8. Go to Section 6.4.4: “Adding a Signer Certificate”.


6–20 Version 3.7

6.4.3 Creating and Extracting a Self-signed Certificate

If you obtained a certificate from a known Certificate Authority, as described in the previous section Section 6.4.2: “Obtaining a Personal Certificate from a Certificate Authority”, skip this section and go Section 6.4.4: “Adding a Signer Certificate”.

To create a new self-signed certificate and store it into the key database file, complete the following steps:

1. Click:

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 machine name of the LDAP server.

3. Accept the defaults for the Version field, which is X509 V3, and for the Key Size field.

4. Either accept the default machine 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, GSKit queries if you want this key to be the default key in the database. You can accept one of them as the default. The default certificate is used at runtime when a label is not provided to select which certificate to use.

This completes the creation of the LDAP server’s personal certificate. It should appear in the Personal Certificates section of the key database file. Use the middle bar of the Key Management Tool to select between the types of certificates kept in the key database file.



The certificate should also appear in the Signer Certificates section of the key database file. When you are in the Signer Certificates section of the Key Database, verify that the new certificate is there.

Next, you must extract your LDAP server’s certificate to a Base64-encoded ASCII data file.

9. Use gsk4ikm to extract your LDAP server’s certificate to a Base64-encoded ASCII data file.

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 .arm.

14. Type the location where you want to store the extracted certificate.

15. Click OK.

16. Copy this extracted certificate to the LDAP server machine.

On the LDAP server, after the client’s personal certificate has been created and added to the client’s key database file, the Certificate Authority that created that client certificate must be recognized as a signer certificate (trusted root).


6–22 Version 3.7

6.4.4 Adding a Signer Certificate

Perform this step on the LDAP server.

To add a signer certificate after the key database file has been created, complete the following steps:

1. Ensure that the certificate which was extracted from the key database file in Section 6.4.3: “Creating and Extracting a Self-signed Certificate” has been copied to the server machine. If it has not been copied, copy it now.

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 .arm.

6. Click OK.

7. Type a label for the signer certificate that you are adding. For example, you can use the machine name of the LDAP client for the label.

8. Click OK.

The self-signed certificate appears in the client’s Key Database as a signer certificate.

9. Highlight the newly added signer certificate, and click View/Edit.

10. Ensure that it is marked as a trusted root by making sure Set the certificate as a trust root is selected.

If the LDAP server’s certificate was generated by a regular Certificate Authority, be sure that the Certificate Authority is listed as a signer certificate and marked as a trusted root. If it is not, then add the Certificate Authority’s certificate as a signer certificate and indicate that it is a trusted root.

The server should now be able to establish an SSL session with the LDAP client.

11. Go to Section 6.4.5: “Testing the SSL access”.



6.4.5 Testing the SSL access

After the LDAP server recognizes the Certificate Authority that created the client’s personal certificate, test SSL access using the following command:

ldapsearch -h servername -Z -K client_keyfile -P key_pw -N \client_label -b "" -s base objectclass=*


This command returns the LDAP base information, which includes the suffixes on the LDAP server. Notice that the -N parameter indicates the label that was specified when the client’s personal certificate was added to the client’s key database file.

Note: Do not specify the LDAP server’s signer certificate label. The -N parameter indicates to GSKit which client certificate is sent to the server when requested. If no label is specified, then the default personal certificate is sent when the server requests the client’s certificate.

The SSL setup is now complete.

Option Description


client_keyfile The fully qualified path name of the generated client key ring.


client_label The label associated with the key, if any. This field is optional and is only needed if the LDAP server is configured to perform both server and client authentication.


6–24 Version 3.7


7Installing and Configuring Policy Director

The Policy Director installation separates file extraction from package configuration. Policy Director uses swinstall to install software packages but does not use the traditional post-install scripts to configure the software. Instead, Policy Director provides a separate configuration utility named pdconfig.

Before starting the installation on a host system, be sure you understand how you want to distribute the Policy Director servers and runtime environment libraries throughout the Policy Director secure domain. For more information, see Chapter 3.

Determine the list of all Policy Director packages to be installed and upgraded on the host system.

First use swinstall to extract all necessary packages and then run pdconfig to configure all packages except the Policy Director Authorization ADK. The Authorization ADK does not require any configuration.

Note: If you have already installed and configured Policy Director Base for HP-UX, Version 3.7, and need to reinstall any package, you must first unconfigure and then remove the package. See Chapter 7.

Chapter 7: Installing and Configuring Policy Director

7–2 Version 3.7

This chapter contains the following sections:� 7.1 Installing Policy Director Runtime Environment� 7.2 Installing Policy Director Management Server� 7.3 Installing Policy Director Authorization Server� 7.4 Installing Policy Director Authorization ADK� 7.5 Configuring Policy Director Runtime Environment� 7.6 Configuring Policy Director Management Server� 7.7 Configuring Policy Director Authorization Server

Installing Policy Director Runtime Environment


7.1 Installing Policy Director Runtime EnvironmentTo install the Policy Director Runtime Environment package, PDRTE, complete the following steps:

1. Log in as user root.

2. Mount the Policy Director Base Version 3.7 for HP-UX CD.

3. Change directory to /<mount-point>/Policy_Director.

4. Use swinstall to install the Policy Director RTE (Runtime Environment) package: # swinstall -s <filepath to package directory> PDRTE

Files are extracted from the CD-ROM and installed on the hard disk.A prompt appears indicating that the Policy Director Runtime package was successfully installed.

5. Choose one of the following actions:� If you are installing a new Policy Director secure domain, go to

Section 7.2: “Installing Policy Director Management Server”.� If you are adding a HP-UX system to an existing Policy Director

secure domain, go to Step 7.

6. If you are adding a HP-UX system to an existing Policy Director secure domain, do not install the Policy Director Management Server. Instead, choose one of the following actions:� If you want to install a Policy Director Authorization Server, go to

Section 7.3: “Installing Policy Director Authorization Server”.� If you want to install the Policy Director Authorization ADK, go to

Section 7.4: “Installing Policy Director Authorization ADK”.� If you do not want to install any other Policy Director packages, go

to Section 7.5: “Configuring Policy Director Runtime Environment”.


7–4 Version 3.7

7.2 Installing Policy Director Management ServerTo install the Policy Director Management Server package, PDMgr, complete the following steps:

1. Verify the following information:� You are logged in as user root.� The Policy Director Base Version 3.7 for HP-UX CD-ROM is

mounted.� The current directory is /<mnt-point>/Policy_Director� You are creating a new Policy Director secure domain, not adding a

system to an existing Policy Director secure domain. There must be only one copy of the Policy Director Management Server running in each secure domain.

2. Use swinstall to install the Policy Director Management Server package, PDMGR: # swinstall -s <package directory> PDFramework.PDMgr

Alternatively, if you want to install all of the PDFramework, type:# swinstall -s <package directory> PDFramework

Files are extracted from the CD-ROM and installed on the hard disk.A prompt appears reminding you to install all packages before configuring any packages.A prompt appears indicating that the Policy Director Management Server package was successfully installed.

3. Choose one of the following actions:� If you want to install a Policy Director Authorization Server, go to

Section 7.3: “Installing Policy Director Authorization Server”.� If you do not want to install a Policy Director Authorization Server,

but want to install the Policy Director Authorization ADK, go to Section 7.4: “Installing Policy Director Authorization ADK”.

� If you do want to install any other Policy Director packages, go to Section 7.5: “Configuring Policy Director Runtime Environment”.

Installing Policy Director Authorization Server


7.3 Installing Policy Director Authorization ServerTo install the Policy Director Authorization Server package, PDAcld, complete the following steps:


mounted.� The current directory is /<mnt-point>/Policy_Director

2. Use swinstall to install the Policy Director Authorization Server package, PDACLD: # swinstall -s <package directory> PDFramework.PDAcld


Files are extracted from the CD-ROM and installed on the hard disk.A prompt appears indicating that the Policy Director Authorization Server package was successfully installed.

3. Choose one of the following actions:� If you want to install the Policy Director Authorization ADK, go to

Section 7.4: “Installing Policy Director Authorization ADK”.� If you do not want to install the Policy Director Authorization ADK,

go to Section 7.5: “Configuring Policy Director Runtime Environment”.

� If you do want to install any other Policy Director packages, go to Section 7.5: “Configuring Policy Director Runtime Environment”.


7–6 Version 3.7

7.4 Installing Policy Director Authorization ADKTo install the Policy Director Authorization ADK, complete the following steps:


mounted.� The current directory is /<mnt-point>/Policy_Director

2. Use swinstall to install the Policy Director Authorization ADK: # swinstall -s <package directory> PDFramework.PDAuthADK


Files are extracted from the CD-ROM and installed on the hard disk.A prompt appears indicating that the package was successfully installed.

3. Go to Section 7.5: “Configuring Policy Director Runtime Environment”.

Configuring Policy Director Runtime Environment


7.5 Configuring Policy Director Runtime Environment To configure the Policy Director Runtime Environment, complete the following steps:

1. Log in as root.

2. Start the Policy Director configuration utility:# /opt/PolicyDirector/bin/pdconfig

The Policy Director Setup Menu appears.

3. Type the menu number for Policy Director ConfigurationThe Policy Director Configuration Menu appears.

4. Type the number for the menu item for Policy Director Runtime (PDRTE) Configuration.

5. Choose one of the following actions:� If you are configuring a new Policy Director secure domain, and will

be configuring the Policy Director Management Server on this same system, go to Section 7.5.1: “Configuring Runtime Environment for a New Secure Domain”.

� If you are adding a Runtime Environment to an existing secure domain, go to Section 7.5.2: “Configuring Runtime Environment into an Existing Secure Domain”.

7.5.1 Configuring Runtime Environment for a New Secure DomainA message appears indicating that the package has been successfully configured.

1. Press Enter to continue.The Policy Director Configuration Menu appears.

2. Go to Section 7.6: “Configuring Policy Director Management Server”.


7–8 Version 3.7

7.5.2 Configuring Runtime Environment into an Existing Secure Domain

If the Policy Director Management Server package has not been installed on this system, a prompt appears asking if you will be installing the Management Server package. � If you answer “yes”, the configuration utility exits. In this case, you

must use swinstall install the Management Server package before configuring the Runtime Environment.

� If you answer no, you are prompted to supply information about the Policy Director secure domain into which this Runtime Environment is being configured.

1. Enter the number for the user registry type.

2. Enter the LDAP server hostname.

3. Enter the LDAP server port number. The default value is 389.

4. Enter the hostname of the Policy Director Management Server machine. For example, tivoli007.ibm.com.

5. Enter the SSL listening port used by the Policy Director Management Server.A message appears indicating that the Policy Director CA Certificate is required. This is the Certificate file that you created when configured the Policy Director Management Server.A prompt appears requesting the filename for the local copy of the Certificate File.

6. Enter the full pathname of the SSL Certificate file.A message appears indicating that the package has been successfully configured.


Configuring Policy Director Runtime Environment


8. Choose one of the following actions:� If you want to configure the Policy Director Management Server, go

to Section 7.6: “Configuring Policy Director Management Server”.� If you want to configure the Policy Director Authorization Server, go

to Section 7.7: “Configuring Policy Director Authorization Server”.� If you are finished configuring Policy Director, type “x” and press

Return.


7–10 Version 3.7

7.6 Configuring Policy Director Management ServerTo configure the Policy Director Management Server, complete the following steps:

1. Log in as root.



3. Type the menu number for Policy Director Configuration.The Policy Director Configuration Menu appears.

4. Type the number for the menu item for Policy Director Management Server (PDMgr) Configuration.A prompt appears asking you to choose a user registry type.

5. Choose one of the following actions:� If you want to use an LDAP User Registry, type “2” and press Enter.

Go to Section 7.6.1: “Configuring Management Server with an LDAP User Registry”.

� If you want to use a DCE User Registry, type “1” and press Enter. Go to Section 7.6.2: “Configuring Management Server with a DCE User Registry”.

� If you want to use a Lotus Domino user registry, please see the Policy Director Release Notes.

Configuring Policy Director Management Server


7.6.1 Configuring Management Server with an LDAP User RegistryA prompt appears requesting you to enter the user name of the DCE cell administrator.

1. Enter the name of the cell administrator.A prompt appears requesting the Cell Administrator password.

2. Enter the Cell Administration password.A series of prompts appears for configuring communication between the Policy Director Management Server and the LDAP server.

3. Enter the required information for the LDAP server configuration:� LDAP server hostname� LDAP server port number

Note: This is the non-SSL port number

A prompt appears requesting the LDAP administrator user DN.

4. Enter the name (DN) for the LDAP administrative user.A prompt appears requesting the password for the LDAP administrator user.

5. Enter the password for the LDAP administrative user.A message appears, indicating that you must provide a password for the Policy Director Administrator account. The message states that the administrator name is sec_master.A prompt appears requesting a password for the Policy Director Administration account.

6. Enter a password for the Policy Director Administration account.

7. Enter the password again for confirmation.A question appears, asking if you want to enable SSL communication between the Policy Director Management Server and the LDAP server.

8. If you want to enable SSL communication, type “y” and press Enter. If you do not want to enable SSL communications, type “n” and press Enter.

9. If you disabled SSL communication, go to the next step. If you have enabled SSL communication, provide the following values when prompted:


7–12 Version 3.7

� LDAP SSL Client Key File Location� SSL Client Certificate Label (optional)The client certificate label is usually not required. This label is needed only when the LDAP server is configured to ask for client-side certificates. Typically, LDAP servers require only server-side certificates. If your LDAP server does not require client-side certificates, you can just press Enter at this prompt.� SSL Client Key File Password� LDAP Server SSL port number. The default port is 636.

10. Enable GSO database access by providing the LDAP DN for the GSO database suffix, which you added in Section 4.3 “Installing or Upgrading Policy Director Security Schema”.For example:o=tivoli,c=us

11. When prompted, enter values needed for generation of an SSL server certificate that will be used for SSL communication between the Management Server and any Policy Director Authorization Servers that are subsequently added to the secure domain:� SSL server port for Policy Director Management ServerPress return to accept the default port of 7135. � SSL certificate lifetimePress Enter to accept the default value of 365 days.The SSL certificate is created and configured. This can take several minutes.A message appears indicating that the SSL configuration has completed successfully. Another message lists the name of the text file in which the SSL certificate is stored:/opt/PolicyDirector/ivmgrd/keytabs/pdacert.b65

12. Record the file name of the stored SSL certificate.When you install Policy Director Authorization Server on other systems, you can optionally configure those Authorization Servers to use SSL communication with this Management Server. To enable SSL communication, you will need to copy the SSL certificate from this system to the systems that run the Authorization Servers.



A message appears indicating that the Management Server is being started.The Policy Director configuration utility configures a Directory Services Broker. A series of messages list each automated step as it completes.A message appears indicating that the Directory Services Broker was successfully installed.


14. Choose one of the following actions:� If you want to configure a Policy Director Authorization Server, go

to Section 7.7: “Configuring Policy Director Authorization Server”.� If you are finished with Policy Director configuration, type “x” and

press Enter. Policy Director configuration is now complete.


7–14 Version 3.7

7.6.2 Configuring Management Server with a DCE User RegistryA prompt appears requesting you to enter the user name of the DCE cell administrator.

1. Enter the name of the Cell Administrator.A prompt appears requesting the Cell Administrator password.

2. Enter the Cell Administration password.You are prompted to enter values necessary to configure an SSL server certificate. Policy Director uses this certificate during SSL communications between the Management Server and the Authorization Server.

3. When prompted, enter values needed for generation of an SSL server certificate:� SSL server port for Policy Director Management ServerPress return to accept the default port of 7135. � SSL certificate lifetimePress Enter to accept the default value of 365 days.The SSL certificate is created and configured. This can take several minutes.A message appears indicating that the SSL configuration has completed successfully. Another message lists the name of the text file in which the SSL certificate is stored:/opt/PolicyDirector/ivmgrd/keytabs/pdacert.b65

4. Record the file name of the stored SSL certificate. When you install Policy Director Authorization Server on other systems, you can optionally configure those Authorization Servers to use SSL communication with this Management Server. To enable SSL communication, you will need to copy the SSL certificate from this system to the systems that run the Authorization Servers.The Policy Director configuration utility configures a Directory Services Broker. A series of messages list each automated step as it completes.A message appears indicating that the PDMgr package installation was successful. The Policy Director Configuration Menu appears.



5. Choose one of the following actions:� If you want to configure a Policy Director Authorization Server, go

to Section 7.7: “Configuring Policy Director Authorization Server”.� If you are finished with Policy Director configuration, type “x” and

press Enter. Policy Director configuration is now complete.


7–16 Version 3.7

7.7 Configuring Policy Director Authorization ServerComplete the following actions:

1. Log in as root.

2. Choose one of the following actions:� If you are configuring the Authorization Server on the same host

system as the Policy Director Management Server, continue to the next step.

� If you are configuring the Authorization Server on a different host system from the Policy Director Management Server, obtain the SSL Certificate file from the Management Server system. Use a file transfer program, such as ftp, to place a copy of the file in a location of your choice. For example:

/opt/PolicyDirector/acld/keytabs/pdacert.b64



4. Type the menu number for Policy Director ConfigurationThe Policy Director Configuration Menu appears.

5. Type the number for the menu item for Policy Director Authorization Server (PDAcld) Configuration. Press Enter.A prompt appears requesting you to enter the user name of the DCE cell administrator.

6. Enter the name of the Cell Administrator.A prompt appears requesting the Cell Administrator password.

7. Enter the Cell Administrator password.

8. Go to the section that matches the type of user registry used in your Policy Director secure domain:� Section 7.7.1: “Configuring Authorization Server with an LDAP

User Registry”� Section 7.7.2: “Configuring Authorization Server with a DCE User

Registry”

Configuring Policy Director Authorization Server


7.7.1 Configuring Authorization Server with an LDAP User RegistryThe Authorization Server configuration continues:

A prompt appears requesting the LDAP administrator user DN.

1. Enter the name (DN) for the LDAP administrative user. To accept the default value of cn=root, press Enter.A prompt appears requesting the password for the LDAP administrator user.

2. Enter the password for the LDAP administrative user.A question appears, asking if you want to enable SSL communication between the Policy Director Authorization server and the LDAP server.

3. If you want to enable SSL communication, type “y” and press Enter. If you do not want to enable SSL communications, type “n” and press Enter.

4. If you disabled SSL communication, go to the next step. If you have enabled SSL communication, provide the following values when prompted:� LDAP SSL Client Key File Location� SSL Client Certificate Label (optional)The client certificate label is usually not required. This label is needed only when the LDAP server is configured to ask for client-side certificates. Typically, LDAP servers require only server-side certificates. If your LDAP server does not require client-side certificates, you can just press Enter at this prompt.� SSL Client Key File Password� LDAP Server SSL port number. The default port is 636.

5. A prompt appears asking for the password the Policy Director Administrator. This Policy Director Administrator is the LDAP user sec_master. Enter the name and password for the Policy Director Administrator sec_master.A message appears stating that the SSL certificate is being created. Creation of the SSL certificate can take several minutes.A message appears stating the SSL configuration has successfully completed.The Policy Director Authorization Server starts.


7–18 Version 3.7

A message appears indicating that the Policy Director Authorization Server (PDAcld) package configuration was successful.


7. To exit the Policy Director Configuration, press Enter to accept the default of “x”.

7.7.2 Configuring Authorization Server with a DCE User RegistryA message appears stating that the SSL certificate is being created. Creation of the SSL certificate can take several minutes.A message appears stating the SSL configuration has successfully completed.The Policy Director Authorization Server starts.A message appears indicating that the Authorization Server (PDAcld) package configuration was successful.




8Upgrading Policy Director

This chapter contains the following sections:

� 8.1 Policy Director Version 3.7 Upgrade Support

� 8.2 Overview of the Upgrade Process

� 8.3 Preserving the Policy Director Version 3.6 Configuration

� 8.4 Upgrading Software Dependencies

� 8.5 Extracting Runtime Environment Files

� 8.6 Extracting Management Server Files

� 8.7 Extracting Authorization Server Files

� 8.8 Extracting Authorization ADK Files

� 8.9 Upgrading the Runtime Environment Configuration

� 8.10 Upgrading the Management Server Configuration

� 8.11 Upgrading the Authorization Server Configuration

Chapter 8: Upgrading Policy Director

8–2 Version 3.7

8.1 Policy Director Version 3.7 Upgrade Support

Policy Director Version 3.7 supports a complete upgrade from Policy Director Version 3.6 The upgrade automatically preserves existing configuration information, archives Version 3.6 files, and then installs and configures Version 3.7 files.

You should upgrade all systems within a Policy Director secure domain to Version 3.7. Policy Director Version 3.7 and Version 3.6 cannot coexist in the same secure domain.

Upgrade one system at a time, but complete the upgrade on all systems in the secure domain, in order to maintain full Policy Director functionality.

8.1.1 Version 3.7 Package Naming Conventions

The Policy Director naming conventions for swinstall packages have changed for Version 3.7. The following table shows how the Version 3.6 naming conventions have changed for Version 3.7.

Policy Director Version 3.7 Package

Version 3.6 Packages

Version 3.7 Packages

Runtime Environment IVBase PDRTE

Management Server IVMgr PDMgr

Authorization Server IVAcld PDAcld

Authorization ADK IVAuthADK PDAuthADK

WebSEAL IVNet/IVWeb PDWeb

NetSEAL IVNet/IVTrap PDNet

Management Console IVConsole PDConsole

Policy Director Version 3.7 Upgrade Support


8.1.2 Components That Are Upgraded

The following Policy Director 3.6 components contain configuration data that must be saved:

� Policy Director Management Server (IVMgr)

� Policy Director WebSEAL Server (IVNet/IVWeb)

You need to preserve the configuration data before beginning the Policy Director Version 3.7 upgrade installation. You do not need to remove the Policy Director 3.6 version of these components.

The following Policy Director 3.6 components do not contain configuration data that must be saved, but are upgraded during the Policy Director Version 3.7 upgrade installation:

� Policy Director Authorization Server (IVAcld)

� Policy Director Base (IVBase)

You do not need to remove either of these components before beginning the Policy Director Version 3.7 upgrade.

8.1.3 Components that Are Not Upgraded

Several Policy Director components do not contain any configuration information that must be preserved, and are not upgraded during the Policy Director Version 3.7 upgrade installation.

You do not need to manually preserve any configuration information for these components. The Version 3.7 installation replaces the Version 3.6 files.

For each component listed below, you should remove the Version 3.6 component before installing the Version 3.7 component:

� Policy Director Authorization ADK (IVAuthADK)

� Policy Director NetSEAL Trap (IVTrap)

� Policy Director Management Console (IVConsole)

8.1.4 Supported Upgrade Paths

You can upgrade Policy Director Version 3.6 to Policy Director Version 3.7.

Automated upgrade of previous Policy Director versions to Version 3.7 is not supported.


8–4 Version 3.7

8.2 Overview of the Upgrade Process

The upgrade of Policy Director Version 3.6 to Policy Director Version 3.7 consists of the several tasks. You must complete each task in the correct order. An overview of each task is presented in the following sections:

1. Preparation of a Version 3.6 System for Upgrading (Section 8.2.1)

2. Installation of New Versions of Supporting Software (Section 8.2.2)

3. Removal of Policy Director Packages that are not Upgraded (Section 8.2.3)

4. Extraction of Policy Director Version 3.7 Packages (Section 8.2.4)

5. Upgrade of Policy Director Version 3.7 Package Configurations (Section 8.2.5)

6. Upgrading the Version 3.6 ACLs (Section 8.2.6)

8.2.1 Preparation of a Version 3.6 System for Upgrading

You must preserving the existing Version 3.6 configuration files, for later use by the Version 3.7 automated upgrade configuration program. You can preserve most information by using the migrate tool. You may have to preserver some customized information manually.

Step-by-step instructions for this task are provided in Section 8.3: “Preserving the Policy Director Version 3.6 Configuration”.

8.2.2 Installation of New Versions of Supporting Software

Before installing Policy Director Version 3.7, you must upgrading the software that Policy Director requires. This includes installing the new release of DCE. If an LDAP user registry is used, this includes installing the new release of LDAP.

You must retain user and group information from the appropriate user registry during this step. Follow the instructions in either your DCE documentation or your LDAP documentation for migrating user and group information.

The Policy Director Version 3.7 automated upgrade does not preserve and restore DCE or LDAP user registry information

For more information on this task, see Section 8.4: “Upgrading Software Dependencies”.

Overview of the Upgrade Process


8.2.3 Removal of Policy Director Packages that are not Upgraded

Some of the Policy Director Version 3.6 packages are not upgraded during the Policy Director Version 3.7 upgrade installation. These packages should be removed before extracting the Policy Director Version 3.7 files.

None of these packages contains data that must be preserved.

Remove any of the following packages that are installed on your Policy Director Version 3.6 system:




8.2.4 Extraction of Policy Director Version 3.7 Packages

This task consists of running swinstall to extract the files contained in each of the necessary Version 3.7 packages.

During the installation of the Version 3.7 Runtime Environment, all Policy Director Version 3.6 files are saved in an archive directory. This occurs prior to the extraction of the Version 3.7 files

The installation of Version 3.7 Management Server, Authorization Server, and Authorization ADK consists only of file extractions. These swinstall sessions appear identical to the swinstall sessions for these packages in a non-upgrade environment.

The use of swinstall is described in the following sections:

� Extracting Runtime Environment Files (Section 8.5)

� Extracting Management Server Files (Section 8.6)

� Extracting Authorization Server Files (Section 8.7)

� Extracting Authorization ADK Files (Section 8.8)


8–6 Version 3.7

8.2.5 Upgrade of Policy Director Version 3.7 Package Configurations

Configuring the Policy Director Version 3.7 packages. This task consists of running the pdconfig utility to upgrade the configuration for each of the Policy Director Version 3.7 packages.

The pdconfig utility uses Version 3.6 configuration information during the configuration of the Runtime Environment, Management Server, and Authorization Server packages.

The Authorization ADK requires no configuration.

The tasks in this step are described in the following sections:

� Upgrading the Runtime Environment Configuration (Section 8.9)

� Upgrading the Management Server Configuration (Section 8.10)

� Upgrading the Authorization Server Configuration (Section 8.11)

8.2.6 Upgrading the Version 3.6 ACLs

After you have completed the upgrade of all of the Policy Director components, you must make some manual edits to the default administration ACL policies.

Note: If you are upgrading Policy Director WebSEAL, you should complete the WebSEAL upgrade before upgrading the ACLs.

The instructions for upgrading the ACLs are provided in Section 8.12: “Upgrading ACLs from Policy Director 3.6”.

Preserving the Policy Director Version 3.6 Configuration


8.3 Preserving the Policy Director Version 3.6 Configuration

Go to the system that runs the Policy Director Version 3.6 Management Server (ivmgrd). Complete the instructions in the following sections:

� Obtaining and Installing the Migration Tool (Section 8.3.1)

� Preserving Policy Director Configuration Data (Section 8.3.2)

� Preserving Customized Configuration File Entries (Section 8.3.3)

8.3.1 Obtaining and Installing the Migration Tool

Perform the following steps to install the migration tool package:

1. Log in as root

2. Go to the Policy Director supplemental file download location:

http://www.tivoli.com/support/secureway/policy_dir/downloads.html

3. Select Tivoli Secureway Policy Director 3.6 migration tool.

4. Download and print the Migration Guide documentation (PDF format).

5. Select the migration package for the HP-UX platform.

6. Download and install the migration package. Install the HP-UX version to the following location:

/opt/migration

Note: The upgrade depends on the migration package being installed in this directory.


8–8 Version 3.7

8.3.2 Preserving Policy Director Configuration Data

1. Verify that the Policy Director Management Server is running.

2. Login as the DCE cell administrator. For example:

# dce_login cell_admin <password>

3. Change directory to:

/opt/migration

4. Enter the following command:

# ./migrate -f acl_backup.xml -t backup -s acls

Note: You must specify the backup file acl_backup.xml for use with the Policy Director Version 3.7 upgrade. The migrate tool accepts other filenames as command line arguments but the Version 3.7 upgrade only recognizes acl_backup.xml

5. If your Policy Director secure domain includes a WebSEAL server that uses smart junctions, make sure the WebSEAL server is running, Back up the junction information before installing Policy Director Version 3.7.

# ./migrate -f jct_backup.xml -t backup -s webseal

You must use jct_backup.xml as the backup file. The Version 3.7 upgrade looks specifically for this file.

Note: Do not use the migrate tool to preserve user registries. Preserve your user registries when upgrading DCE or LDAP, as described in Section 8.4: “Upgrading Software Dependencies”.

8.3.3 Preserving Customized Configuration File Entries

The Policy Director Version 3.7 upgrade carefully preserves information from the Policy Director configuration files. However, there can be customized entries that the upgrade does not recognize. You must manually add these customized settings back into the configuration files after the Version 3.7 configuration has completed.

Example of information that is not preserved:

� User-specified MIME types

� ldap.conf information such as the location of LDAP replicas

Upgrading Software Dependencies


8.4 Upgrading Software Dependencies

Before installing Policy Director Version 3.7 software, verify that the Policy Director Version 3.7 software dependencies have been met. The exact software dependencies vary depending on the components of Policy Director Version 3.7 that you are using.

In order to upgrade an existing Policy Director secure domain, you should retain the same configuration of user registry software such as DCE or LDAP.

8.4.1 Upgrading the DCE Infrastructure

Verify that you have correctly installed and configured HP DCE. Duplicate the DCE cell configuration, including the location of DCE servers and DCE clients.

Note: If your Policy Director secure domain uses a DCE user registry, you must preserve user registry information when moving from a prior version of HP DCE to the current version. Policy Director Version 3.7 upgrade does not preserve DCE user and group information.

See the HP DCE documentation for installation and configuration information.

8.4.2 Upgrading LDAP Servers and Clients

Verify that you have correctly installed and configured IBM SecureWay Directory Version 3.2 for HP-UX. Duplicate the LDAP configuration, including the location of LDAP servers and LDAP clients.

IBM Secureway Directory Version 3.2 uses IBM DB2 Version 6.0 and IBM GSKit Version 4.0. See the IBM DB2 Version 6.0 documentation and the IBM SecureWay Directory Version 3.2 documentation for more information.

Note: When upgrading the LDAP server, you must preserve LDAP user and group information. Policy Director Version 3.7 upgrade does not preserve LDAP user and group information.

Netscape LDAP Server

Policy Director Version 3.7 supports the same version of the Netscape LDAP server (4.1) as Policy Director Version 3.6. You do not have to upgrade Netscape LDAP server.


8–10 Version 3.7

8.5 Extracting Runtime Environment Files

To install the Policy Director Runtime Environment package, PDRTE, complete the following steps:

1. Log in as user root.

2. Remove any of the following packages that are installed on your Policy Director Version 3.6 system:




3. Mount the Policy Director Base for HP-UX CD.

4. Change directory to /<mount-point>/Policy_Director

5. Use swinstall to install the Policy Director RTE (Runtime Environment) package:

# swinstall -s <package directory> PDRTE

6. When prompted to continue, type “y” and press Enter.

A message appears indicating that a previous version of this package is configured on the system.

A prompt appears requesting the location of the ACL Data file.

Note: This is the file you created when you backed up ACL Data in Section 8.3.2: “Preserving Policy Director Configuration Data”.

7. Enter the location of the ACL Data file and press Enter.

A message appears, indicating that files are being backed up.

All files contained in /opt/intraverse are archived in the following directory:

/opt/PolicyDirector/PD36/archive

Files are extracted from the CD-ROM and installed on the hard disk.

A prompt appears indicating that the Policy Director Runtime package was successfully installed.

Extracting Runtime Environment Files


8. Choose one of the following actions:

� If you are upgrading a system that runs the Policy Director Management Server, go to Section 8.6: “Extracting Management Server Files”.

� If you are upgrading a system that runs the Policy Director Authorization Server, go to Section 8.7: “Extracting Authorization Server Files”.

� If you are upgrading a system that has the Policy Director Authorization ADK, go to Section 8.8: “Extracting Authorization ADK Files”.


8–12 Version 3.7

8.6 Extracting Management Server Files

To install the Policy Director Management Server package PDMgr, complete the following steps:

1. Verify the following information:

� You are logged in as user root.

� The Policy Director Base for HP-UX CD is mounted.

� The current directory is /<mount-point>/Policy_Director

� You are upgrading a system that already runs the Policy Director Management Servers. There must be only one copy of the Policy Director Management Server running in each secure domain.

2. Use swinstall to install the Policy Director Management Server package, PDMGR:

# swinstall -s <package directory> PDFrameWork.PDMgr




A message appears stating that the Management Server (ivmgrd) is already running on this system. The message states that the process will be killed. A prompt appears asking if you want to continue.

4. Type “y” and press Enter.

A message appears stating that the Directory Service Broker (dsb) is already running on this system. The message states that the process will be killed. A prompt appears asking if you want to continue.



A prompt appears indicating that the Policy Director Management Server package was successfully installed.

Extracting Management Server Files



� If you want to install a Policy Director Authorization Server, go to Section 8.7: “Extracting Authorization Server Files”.

� If you want to install the Policy Director Authorization ADK, go to Section 8.8: “Extracting Authorization ADK Files”.

� If you do want to install any other Policy Director packages, go to Section 8.9: “Upgrading the Runtime Environment Configuration”.


8–14 Version 3.7

8.7 Extracting Authorization Server Files

To install the Policy Director Authorization Server package PDAcld, complete the following steps:





2. Use swinstall to install the Policy Director Authorization Server package, PDACLD:

# swinstall -s <package directory> PDFrameWork.PDAcld



A message appears stating that the Authorization Server (ivacld) is already running on this system. The message states that the process will be killed. A prompt appears asking if you want to continue.



A prompt appears indicating that the Policy Director Authorization Server package was successfully installed.


� If you want to install the Policy Director Authorization ADK, go to Section 8.8: “Extracting Authorization ADK Files”.

� If you do not want to install the Policy Director Authorization ADK, go to Section 8.9: “Upgrading the Runtime Environment Configuration”.

Extracting Authorization ADK Files


8.8 Extracting Authorization ADK Files

There is no upgrade for the Policy Director Authorization ADK. The Policy Director Version 3.7 for HP-UX Authorization ADK files replace the prior version.

To install the Policy Director Authorization ADK package, complete the following steps:





2. Use swinstall to install the Policy Director Authorization ADK package:

# swinstall -s <package directory> PDFrameWork.PDAuthADK



A prompt appears indicating that the Policy Director Authorization ADK package was successfully installed.

4. Go to Section 8.9: “Upgrading the Runtime Environment Configuration”.


8–16 Version 3.7

8.9 Upgrading the Runtime Environment Configuration


� Configuring the Upgrade Migration File (Section 8.9.1)

� Upgrading the Runtime Environment (Section 8.9.2)

8.9.1 Configuring the Upgrade Migration File

Policy Director Version 3.7 uses the following configuration file:

/opt/Policy_Director/upgrade_tools/migrate.conf

1. Edit the file to contain the correct name for the DCE administrator account on your system. For example:

dce-admin-name = cell_admin

2. If your secure domain uses an LDAP user registry, enter the correct values for the LDAP settings. For example:

domain = o=tivoli,c=us

admin-dn = cn=root

admin-pwd = myPassworD

The configuration file is now ready for the upgrade.

8.9.2 Upgrading the Runtime Environment

The procedures for upgrading a Policy Director configuration are very similar to those used when configuring a new Policy Director secure domain.

1. Log in as root.

2. Start the Policy Director configuration utility:

# /opt/PolicyDirector/bin/pdconfig


3. Type the menu number for Policy Director Configuration

The Policy Director Configuration Menu appears.

Upgrading the Runtime Environment Configuration


4. Type the number for the menu item for Policy Director Runtime Configuration.

The following message appears:

Upgrading...

The following messages may appear:

cdas_server is already running on this system.

This process will be killed by the installation.

A prompt appears asking if you wish to continue.


A message appears indicating that the conf (configuration) file is being updated.

A message appears indicating that the package has been successfully configured.

6. Press Enter to continue.



� If you want to upgrade the Policy Director Management Server configuration, go to Section 8.10: “Upgrading the Management Server Configuration”.

� If you want to upgrade the Policy Director Authorization Server configuration, go to Section 8.11: “Upgrading the Authorization Server Configuration”.

� If you are finished upgrading the Policy Director configuration, type “x” and press Return.

Note: The Authorization ADK does not require any configuration.


8–18 Version 3.7

8.10 Upgrading the Management Server Configuration

Complete the following actions:

1. Log in as root.






4. Type the number for the menu item for Policy Director Management Server (PDMgr) Configuration.


Upgrading...

Updating conf file, please wait.

A prompt appears requesting you to enter the user name of the DCE cell administrator.

1. Enter the name of the Cell Administrator.

A prompt appears requesting the Cell Administrator password.

2. Enter the Cell Administration password.

You are prompted to enter values necessary to configure an SSL server certificate. Policy Director uses this certificate during SSL communications between the Management Server and the Authorization Server.

3. When prompted, enter values needed for generation of an SSL server certificate:

� SSL server port for Policy Director Management Server

Press return to accept the default port of 7135.

� SSL certificate lifetime

Press Enter to accept the default value of 365 days.

The SSL certificate is created and configured. This can take several minutes.

Upgrading the Management Server Configuration


A message appears indicating that the SSL configuration has completed successfully. Another message lists the name of the text file in which the SSL certificate is stored.

4. Record the file name of the stored SSL certificate.

Note: When you install Policy Director Authorization Server on other systems, you can configure the Authorization Server to use SSL communication with this Management Server. To enable SSL communication, you will need to copy the SSL certificate from this system to the systems that run the other Policy Director servers.

The Policy Director Management Server starts.

A prompt appears requesting the location of the ACL Data file. This is the ACL data file you created in Section 8.3.2: “Preserving Policy Director Configuration Data”.

5. Enter the name of the ACL Data file. If you used the default file name of /opt/migration/acl_backup.xml, you can just press Enter.


Proceeding with Migration...

The Policy Director configuration utility configures a Directory Services Broker. A series of messages list each automated step as it completes.

A message appears indicating that the PDMgr package installation was successful.



� If you want to upgrade a Policy Director Authorization Server configuration, go to Section 8.11: “Upgrading the Authorization Server Configuration”.

� If you are finished upgrading the Policy Director configuration, type “x” and press Enter. Policy Director configuration is now complete.

Note: The Authorization ADK does not require any configuration.


8–20 Version 3.7

8.11 Upgrading the Authorization Server Configuration

Complete the following actions:

1. Log in as root.






4. Type the number for the menu item for Policy Director Authorization Server (PDAcld) Configuration. Press Enter.


Upgrading...

Updating conf file, please wait.


5. Enter the name of the Cell Administrator.



A message appears stating that the SSL certificate is being created.


Requesting signed certificate from the Management Server

Creation of the SSL certificate can take several minutes.

A message appears stating the SSL configuration has successfully completed.

The Policy Director Authorization Server starts.

A message appears indicating that the Authorization Server (PDAcld) package configuration was successful.

1. Press Enter to continue.



Upgrading ACLs from Policy Director 3.6


8.12 Upgrading ACLs from Policy Director 3.6

Policy Director Version 3.7 uses a slightly different ACL policy scheme than the scheme used by Policy Director Version 3.6. After you complete the standard upgrade process from Version 3.6 to Version 3.7, you must make some manual edits to the default administration ACL policies. These include:

� default-root

� default-webseal

� default-management

� default-netseal

� default-replica

The default ACL policies installed on the upgraded system are only a replica of the default ACLs for Policy Director Version 3.6. Policy Director Version 3.7 eliminates three permission bits and adds four new ACL permission bits. This change affects the permission settings of the new default administration ACL policies.

Permission bits removed for Version 3.7 include:

Permission bits added for Version 3.7 include:

In addition, there are some standard permission bits that are now set differently in the default administration ACLs:

Removed Bits Operation Category

A audit Base

P privacy Base

I integrity Base

New Bits Operation Category

N create Base

W password Base

A add Base

B bypass time-of-day POP setting Base


8–22 Version 3.7

If you want your Version 3.7 administration ACL policy settings to have the equivalent characteristics as the Version 3.6 administration ACL settings, you must manually edit the upgraded default administration ACL policy settings, using the information provided in the table below.

The table shows the additions to the upgraded Version 3.7 ACL policies that are required to conform to a Policy Director Version 3.7 default installation.

Refer to Section 3.10 of the Tivoli SecureWay Policy Director Base Administration Guide for a complete summary of the default administration ACL policies for Policy Director Version 3.7.

Refer to Section A.2 of the Tivoli SecureWay Policy Director Base Administration Guide for the pdadmin acl command reference.

New Bits Operation Category

b browse Base

T traverse Base

m modify Generic

s server administration Generic

v view Generic

d delete Generic

default-root

default-webseal

default-management

default-netseal

default-replica

usercell_admin

mdv v NWA – —

groupivmgrd-servers

— — – — —

groupiv-admin

mdv v NWA – —

unauthenticated — — – — —

any-other — — – — —

groupwebseal-servers

– b – Tb –

Troubleshooting


8.13 Troubleshooting

8.13.1 Running the Upgrade Scripts Manually

If a portion of the upgrade fails, but the upgrade configuration finishes, you can manually run the upgrade scripts for each Policy Director package:

The scripts are:

/opt/PolicyDirector/bin/PDRTE_upgrade

/opt/PolicyDirector/ivmgr/bin/PDMgr_upgrade

/opt/PolicyDirector/secmgr/bin/PDWeb_upgrade

8.13.2 Restoring Saved Data Manually

If the migration restore of ACL data fails and the PDMgr_upgrade continues to the end, you can run migration restore manually. Use the following commands:

dce_login cell_admin cell

cd /opt/PolicyDirector/upgrade_tools

./PD36_restore -f /opt/migration/acl_backup.xml -t restore -sacls -e ./dce_aclerror.xml

If the migration restore of WebSEAL data fails and the PDWeb_upgrade continues to the end, you can run migration restore manually. Use the following commands:

dce_login cell_admin cell

cd /opt/PolicyDirector/upgrade_tools

./PD36_restore -f /opt/migration/jct_backup.xml -t restore -swebseal -e ./dce_weberror.xml


8–24 Version 3.7


9Removing Policy Director Base

Removal of Policy Director Base for HP-UX, Version 3.7 is a two part process. The first part is to use the pdconfig tool to unconfigure each package that is to be removed. The second part is to use swremove to remove the files for each package.

Unconfigure any Policy Director Applications, such as Policy Director WebSEAL or Policy Director NetSEAL, before unconfiguring Policy Director Management Server and Policy Director Runtime Environment.

If you want to unconfigure more than one Policy Director Base package, unconfigure the packages in the order presented in the unconfiguration menu.

Note: You do not have to unconfigure the Policy Director Application Development Kit before removing it.

This chapter contains the following sections:

� 9.1 Unconfiguring Policy Director Authorization Server

� 9.2 Unconfiguring Policy Director Management Server

� 9.3 Unconfiguring Policy Director Runtime Environment

� 9.4 Removing Policy Director Authorization ADK

� 9.5 Removing Policy Director Authorization Server

� 9.6 Removing Policy Director Management Server

� 9.7 Removing Policy Director Runtime Environment

Chapter 9: Removing Policy Director Base

9–2 Version 3.7

9.1 Unconfiguring Policy Director Authorization Server

1. Log in as root.c


# cd /opt/PolicyDirector/bin


# ./pdconfig


4. Type the menu number for Policy Director Unconfiguration

The Policy Director Unconfiguration Menu appears.

5. Type the number for the menu item for Policy Director Authorization Server you want to unconfigure.


6. Enter the name of the cell administrator.


7. Enter the Cell Administration password.


� If the Policy Director secure domain uses a DCE user registry, go to the following section: Section 9.1.1: “Unconfiguring Authorization Server with a DCE User Registry”.

� If the Policy Director secure domain uses an LDAP user registry, go to the following section: Section 9.1.2: “Unconfiguring Authorization Server with an LDAP User Registry”

Unconfiguring Policy Director Authorization Server


9.1.1 Unconfiguring Authorization Server with a DCE User Registry� A message appears indicating that the Management Server has been

stopped.

� A message appears indicating that the Directory Services Broker has been unconfigured.

� A message appears indicating that the Authorization Server package has been successfully unconfigured.

The unconfiguration is complete.

9.1.2 Unconfiguring Authorization Server with an LDAP User Registry

A prompt appears requesting the DN of the LDAP administrative user.

1. Enter the name (DN) for the LDAP administrative user.

A prompt appears requesting the password for the LDAP administrator user.

2. Enter the password for the LDAP administrative user.

� A message appears indicating that the Management Server is being stopped.

� A message appears indicating that the Directory Services Broker is being stopped.

� A message appears indicating that the Authorization Server package has been successfully unconfigured.



9–4 Version 3.7

9.2 Unconfiguring Policy Director Management Server

1. Log in as root.


# cd /opt/PolicyDirector/bin


# ./pdconfig




5. Type the number for the menu item for Policy Director Management Server.

Note: Unconfiguring the Management Server removes all configuration and authorization information from the Policy Director secure domain. This includes information used by Policy Director applications such as Policy Director WebSEAL and Policy Director NetSEAL.

A prompt appears, warning you that you are about to remove all configuration and authorization information. Another prompts asks if you wish to continue.

6. To continue, enter “y”.


7. Enter the name of the cell administrator.




� If the Policy Director secure domain uses a DCE user registry, go to the following section: Section 9.2.1: “Unconfiguring Management Server with a DCE User Registry”.

� If the Policy Director secure domain uses an LDAP user registry, go to the following section: Section 9.2.2: “Unconfiguring Management Server with an LDAP User Registry”

Unconfiguring Policy Director Management Server


9.2.1 Unconfiguring Management Server with a DCE User Registry� A message appears indicating that the Management Server has been

stopped.

� A message appears indicating that the Directory Services Broker has been unconfigured.

� A message appears indicating that the Management Server package has been successfully unconfigured.


9.2.2 Unconfiguring Management Server with an LDAP User Registry

A prompt appears requesting the DN of the LDAP administrative user.

1. Enter the name (DN) for the LDAP administrative user.

A prompt appears requesting the password for the LDAP administrator user.

2. Enter the password for the LDAP administrative user.

� A message appears indicating that the Management Server is being stopped.

� A message appears indicating that the Directory Services Broker is being unconfigured.

� A message appears indicating that the Management Server is being unconfigured.

� A message appears indicating that the configuration of the Directory Services Broker has finished.



9–6 Version 3.7

9.3 Unconfiguring Policy Director Runtime Environment

Note: If the Management Server is configured on the same system, unconfigure it before unconfiguring the Runtime Environment.

1. Log in as root.


# cd /opt/PolicyDLirector/bin


# ./pdconfig




5. Type the number for the menu item for Policy Director Runtime (PDRTE) Unconfiguration.

A message appears indicating the Runtime Environment has been successfully unconfigured.


Removing Policy Director Authorization ADK


9.4 Removing Policy Director Authorization ADK

You do not need to unconfigure Policy Director Authorization ADK before removing it.

To remove Policy Director Authorization ADK, complete the following steps:

1. Log in as root.


# swremove PDAuthADK

A prompt appears asking you to confirm the removal of this package.

3. Enter “y”.

� A prompt appears indicating the preremove script is being executed.

� Each files is listed as it removed.

� A prompt appears indicating that the postremove script is being executed.

A message appears indicating that the removal of the software package was successful.


9–8 Version 3.7

9.5 Removing Policy Director Authorization Server

Note: You must unconfigure Policy Director Authorization Server before removing the Authorization Server files. If you have not already unconfigured Authorization Server, go to Section 9.1: “Unconfiguring Policy Director Authorization Server”.

To remove Policy Director Authorization Server, complete the following steps:

1. Log in as root.


# swremove PDAcld

A prompt appears asking you to confirm the removal of this package

3. Enter “y”.





Removing Policy Director Management Server


9.6 Removing Policy Director Management Server

Note: You must unconfigure Policy Director Management Server before removing the Management Server files. If you have not already unconfigured Management Server, go to Section 9.2: “Unconfiguring Policy Director Management Server”.

To remove Policy Director Management Server, complete the following steps:

1. Log in as root.


# swremove PDMgr

A prompt appears asking you to confirm the removal of the package.

3. Enter “y”.






9–10 Version 3.7

9.7 Removing Policy Director Runtime Environment

Note: You must unconfigure Policy Director Runtime Environment before removing the Runtime Environment files. If you have not already unconfigured Runtime Environment, go to Section 9.3: “Unconfiguring Policy Director Runtime Environment”.

To remove Policy Director Runtime Environment, complete the following steps:

1. Log in as root.


# swremove PDRTE

A prompt appears asking you to confirm the removal of this package

3. Enter “y”.



