IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC32-0846-00/… · ·...

IBM Tivoli Access Manager

Performance Tuning GuideVersion 3.9

GC32-0846-00

Note:Before using this information and the product it supports, read the information in Appendix B, “Notices” on page 85.

Second Edition (April 2002)

This edition replaces GC32-0812-00.

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

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vWho should read this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vWhat this book contains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vPublications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viRelated publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiAccessing publications online. . . . . . . . . . . . . . . . . . . . . . . . . . . . . xOrdering publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xProviding feedback about publications . . . . . . . . . . . . . . . . . . . . . . . . . xi

Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiContacting customer support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiConventions used in this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Typeface conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1. Setting up, managing, and tuning the IBM SecureWay Directory server forAccess Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Initial steps for setting up an IBM SecureWay Directory Server . . . . . . . . . . . . . . . . . . 1

Resetting an already populated database . . . . . . . . . . . . . . . . . . . . . . . . . 1Planning disk and memory requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2UNIX operating system tuning for the IBM SecureWay Directory server . . . . . . . . . . . . . . 3General IBM SecureWay Directory tuning. . . . . . . . . . . . . . . . . . . . . . . . . 5Access-Manager-Specific SecureWay Directory set up . . . . . . . . . . . . . . . . . . . . 12Preparing to expand to a large registry . . . . . . . . . . . . . . . . . . . . . . . . . 13

Adding users and groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Do the load of users or groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Add Access Manager ACLs not created by the bulkload utility . . . . . . . . . . . . . . . . . 15Do the tunings in the next section titled ″Tuning after a Large Number of Updates″ . . . . . . . . . . 16Do a DB2 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Tuning after a large number of updates . . . . . . . . . . . . . . . . . . . . . . . . . . 16Redo the DB2 tuning parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Recheck for missing and extra indexes . . . . . . . . . . . . . . . . . . . . . . . . . 16Do a DB2 reorgchk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Do a DB2 runstats on the objectclass table . . . . . . . . . . . . . . . . . . . . . . . . 17Do DB2 statistics tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Start the IBM SecureWay Directory server . . . . . . . . . . . . . . . . . . . . . . . . 18Test the performance of the registry . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 2. Special case IBM LDAP directory tunings . . . . . . . . . . . . . . . . 21Using LDAP cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Setting the LDAP cache parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 21Choosing the LDAP cache values for Access Manager . . . . . . . . . . . . . . . . . . . . 21

Chapter 3. Tuning IBM Tivoli Access Manager WebSEAL . . . . . . . . . . . . . . 25Recommended Access Manager WebSEAL tunings . . . . . . . . . . . . . . . . . . . . . . 25auth-using-compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25user-and-group-in-same-suffix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25default-policy-override-support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Chapter 4. Special case IBM Tivoli Access Manager WebSEAL tunings . . . . . . . . 27LDAP admin account (cn=root) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Load balancing between LDAP replicas . . . . . . . . . . . . . . . . . . . . . . . . . . 27SSL between IBM Tivoli Access Manager and LDAP. . . . . . . . . . . . . . . . . . . . . . 27Automatic migration of IBM SecureWay Policy Directory 3.7 users during authentication . . . . . . . . . 27SSL session cache, user credential cache, and memory use . . . . . . . . . . . . . . . . . . . . 28

© Copyright IBM Corp. 2001,2002 iii

Chapter 5. Tuning the AIX operating system for IBM Tivoli Access Manager and LDAP 29

Chapter 6. Access Manager’s Use of LDAP Directory . . . . . . . . . . . . . . . . 31

Chapter 7. Utilities, scripts, and hints for managing IBM LDAP Directory servers. . . . 33IBM LDAP Directory’s use of DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Distributing the database across multiple physical disks . . . . . . . . . . . . . . . . . . . . 34

Background information on LDAP Directory tablespaces . . . . . . . . . . . . . . . . . . . 34Create file systems and directories on the target disks . . . . . . . . . . . . . . . . . . . . 35Backing up the existing database . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Perform a redirected restore of the database . . . . . . . . . . . . . . . . . . . . . . . 36

DB2 backup and restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Monitoring LDAP performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Update performance and SMP systems . . . . . . . . . . . . . . . . . . . . . . . . . . 39Creating large numbers of users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39The LDAP bulkload utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Disk space requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Bulk loading and ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Using the Access Manager scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Adding a large number of members to a group . . . . . . . . . . . . . . . . . . . . . . 44Adding groups and the DB2 LOGFILSIZ parameter . . . . . . . . . . . . . . . . . . . . . 46Using the group scripts together . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Chapter 8. Process memory size limits . . . . . . . . . . . . . . . . . . . . . . 47Increasing the operating system process memory size limits . . . . . . . . . . . . . . . . . . . 47AIX-specific process size limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Setting the maximum number of AIX data segments that a process can use (LDR_CNTRL) . . . . . . . . 47AIX data segments and LDAP process DB2 connections . . . . . . . . . . . . . . . . . . . 48Verifying process data segment usage . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapter 9. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Appendix A. Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53do_tunings_322.sh and do_tunings_321.sh . . . . . . . . . . . . . . . . . . . . . . . . . 53check_indexes.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54check_ldap_acls.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57fixacls.sh, fixacls2.sh, and fixacls3.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . 59sysstat_tune.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66test_registry_perf.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67mk_test_users.sh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68addpd_to_testusers_ldif.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69incremental_bulkload.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71mk_test_group_ldif.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75addpd_to_groups_ldif.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76incremental_group.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Appendix B. Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

iv IBM Tivoli Access Manager: Performance Tuning Guide

Preface

IBM® Tivoli® Access Manager (Access Manager) is the base software that isrequired to run applications in the Access Manager product suite. It enables theintegration of Access Manager applications that provide a wide range ofauthorization and management solutions. Sold as an integrated solution, theseproducts provide an access control management solution that centralizes networkand application security policy for e-business applications.

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

The IBM Tivoli Access Manager Performance Tuning Guide provides performancetuning information for an environment consisting of IBM Tivoli Access Manager,Version 3.9, with IBM SecureWay Directory defined as the user registry. This guideis regularly updated with the latest performance information regarding AccessManager. This guide supplements the performance tuning sample scripts, locatedat the following Web address:

https://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

This Web page requires a registered user name and password.

Who should read this bookThis guide is for system administrators responsible for setting up, maintaining, andtuning large and small registries of users.

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

Telnetv Lightweight Directory Access Protocol (LDAP) and directory servicesv A supported user registryv Authentication and authorization

What this book containsThis guide contains the following sections:v Chapter 1, “Setting up, managing, and tuning the IBM SecureWay Directory

server for Access Manager”v Chapter 2, “Special case IBM LDAP directory tunings”v Chapter 3,“Tuning IBM Tivoli Access Manager WebSEAL”v Chapter 4,“Special case IBM Tivoli Access Manager WebSEAL tunings”

© Copyright IBM Corp. 2001,2002 v



v Chapter 5,“Tuning the AIX operating system for IBM Tivoli Access Manager andLDAP”

v Chapter 6,“Access Manager’s Use of LDAP Directory”v Chapter 7“Utilities, scripts, and hints for managing IBM LDAP Directory

servers”v Chapter 8,“Process memory size limits”v Chapter 9,“Troubleshooting”

Appendixes

This guide contains the following appendix:v Appendix A, “Scripts”

This appendix provides sample scripts that users can customize. The scripts arealso available at:https://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

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

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

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

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

http://www.ibm.com/redbookshttps://www.tivoli.com/secure/support/documents/fieldguides

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

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

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

vi IBM Tivoli Access Manager: Performance Tuning Guide



http://www.ibm.com/redbooks

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

Base informationv IBM Tivoli Access Manager Base Installation Guide

GC32-0844<(am39_install.pdf)Explains how to install, configure, and upgrade Access Manager software,including the Web portal manager interface.

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

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

WebSEAL informationv IBM Tivoli Access Manager WebSEAL Installation Guide

GC32-0848<(amweb39_install.pdf)Provides installation, configuration, and removal instructions for the WebSEALserver and the WebSEAL application development kit.

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

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

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

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

GC32-0850 (amwas39_user.pdf)Provides installation, removal, and administration instructions for AccessManager for IBM WebSphere® Application Server.

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

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

v IBM Tivoli Access Manager Plug-in for Web Servers User’s GuideGC23-4686 (amws39_user.pdf)

Preface vii

Provides installation instructions, administration procedures, and technicalreference information for securing your Web domain using the plug-in for Webservers.

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

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

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

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

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

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

Technical supplementsv IBM Tivoli Access Manager Performance Tuning Guide

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

v IBM Tivoli Access Manager Capacity Planning GuideGC32-0847 (am39_capplan.pdf)Assists planners in determining the number of WebSEAL, user registry, andbackend Web servers needed to achieve a required workload.

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

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

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

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

viii IBM Tivoli Access Manager: Performance Tuning Guide

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

IBM DB2® Universal Database™

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

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

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

The GSKit package installs the iKeyman key management utility, gsk5ikm, whichenables you to create key databases, public-private key paris, and certificaterequests. The following document is available in the /doc/GSkit directory on theIBM Tivoli Access Manager Base CD for your particular platform:v Secure Sockets Layer Introduction and iKeyman User’s Guide

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

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

(aparent.pdf, lparent.pdf, sparent.pdf, wparent.pdf)Provides installation, configuration, and migration information for IBMSecureWay Directory components on AIX®, Linux, Solaris OperatingEnvironment, and Microsoft® Windows® operating systems.

v IBM SecureWay Directory Release Notes(relnote.pdf)Supplements IBM SecureWay Directory, Version 3.2.2, product documentationand describes features and functions made available to you in this release.

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

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

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

v IBM SecureWay Directory Configuration Schema(scparent.pdf)

Preface ix

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

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

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

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

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

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

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

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

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

You can access the Tivoli Information Center and other sources of technicalinformation from the following Web site:

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

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

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

Ordering publicationsYou can order many Tivoli publications online at the following Web site:

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

You can also order by telephone by calling one of these numbers:v In the United States: 800-879-2755v In Canada: 800-426-4968

x IBM Tivoli Access Manager: Performance Tuning Guide


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

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



v In other countries, for a list of telephone numbers, see the following Web site:http://www.tivoli.com/inside/store/lit_order.html

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

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

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

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

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

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

you are locatedv What information to gather before contacting support

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

Typeface conventionsThe following typeface conventions are used in this book:

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

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

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

Preface xi

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

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

xii IBM Tivoli Access Manager: Performance Tuning Guide

Chapter 1. Setting up, managing, and tuning the IBMSecureWay Directory server for Access Manager

The IBM SecureWay Directory is one of several directories supported by AccessManager. This section provides information on setting up, managing, and tuning alarge registry of users on the IBM SecureWay Directory server. Because IBMSecureWay Directory uses DB2 for storing its information, much of this informationis related to DB2 tuning.

Performance problems can occur with small registries (more than several users), aswell as with large registries (up to thousands of users). This document addressestunings for any size registry.

The information in this document is applicable to both master and replica servers.Notes are made where the steps may differ between the two types of servers.

The information in this section is only for the IBM SecureWay Directory server, notthe client; the client requires no tuning. It is assumed that the IBM SecureWayDirectory Server has been installed and configured. The document does not coverhow to initially configure the IBM SecureWay Directory server. Refer to IBMSecureWay Directory documentation for more information. See IBM SecureWayDirectory.

This document assumes a basic understanding of LDAP and of the design anddeployment of a user name space on LDAP. This knowledge is prerequisite tounderstanding some of the steps in this document. Refer to the following IBMRedbooks for more information:v Understanding LDAP (SG24-4986-00)v LDAP Implementation Cookbook (SG24-5110-00)

These documents can be found online at http://www.redbooks.ibm.com.

Initial steps for setting up an IBM SecureWay Directory ServerThis section describes how to set up a large registry of users with an emptydatabase. The first part of the section describes how to reset an already populatedregistry to make it empty. Skip this section if the IBM SecureWay Directory serverhas been freshly installed and configured. In this case, the database is alreadyempty.

Resetting an already populated databaseIf the IBM SecureWay Directory server is already configured and populated withdata, it can be reset to an empty database using several methods, two of which aredescribed here. One method is to unconfigure, uninstall, reinstall, and reconfigurethe IBM SecureWay Directory server. Another method is to drop and recreate theIBM SecureWay Directory DB2 database. The first method also reset the DB2database and LDAP configuration settings to their defaults. The second methoddoes not. Even if the second method is used, it is a good idea to go through all ofthe subsequent tuning steps to ensure the database is properly tuned.

Some of the files that are not changed as a result of dropping the database arelisted below:

© Copyright IBM Corp. 2001,2002 1

http://www.ibm.com/redbooks

/etc/slapd32.conf/etc/ldapschema/V3.modifiedschema

You should save the original contents of these files, so that they can be restored totheir defaults if necessary.

To drop and create the database used by the IBM LDAP server, do the following:1. Stop the Directory server. On UNIX systems, this can be done by first finding

the process ID of the slapd process:ps –ef | grep slapd

2. Note the slapd process ID from the previous command, then stop the processusing a command similar to the following:kill process_id

where process_id is the process ID returned from the first command.

On Windows systems, stop the IBM LDAP server service.3. Switch to the ldapdb2 instance users. This is done on UNIX systems using the

following command:su – ldapdb2

On Windows systems, enter the following command at a command prompt:db2cmdset DB2INSTANCE=ldapdb2

4. Drop and create the database:db2 drop db ldapdb2db2 create db ldapdb2

5. Exit from the ldapdb2 instance (UNIX systems) using the following command:exit

After the database has been dropped and recreated, the IBM SecureWay Directoryserver must be started to finish the database configuration. Start the IBMSecureWay Directory server with the following command:slapd

Planning disk and memory requirementsThe minimum memory size for an IBM SecureWay Directory server with morethan a million users is 512 MB; the optimum memory size is 1 to 2 GB. For an IBMSecureWay Directory server with fewer than a million users, the optimum memorysize is 256 MB.

The disk space requirements for a server with over a million users depend uponwhether the server machine is to be used to bulk-load the initial set of users andwhich version of the IBM SecureWay Directory server is used (Version 3.2.1 or3.2.2). Following is an explanation of the requirements:v Bulkload: Reserve 7 to 9 GB of disk space for bulk-loading temporary files if

millions of users are to be loaded. The bulkload utility is fastest when all usersare loaded in one pass. Refer to the bulkload section for refinements on the diskrequirements. See “The LDAP bulkload utility” on page 40.

v Accounting and temporary information: The ldapdb2 user’s home directory initiallyholds the entire DB2 database. It also holds accounting and temporaryinformation, like the DB2 transaction log. Reserve 100 MB to 1 GB of disk spacefor this accounting and temporary storage

2 IBM Tivoli Access Manager: Performance Tuning Guide

v DB2 database tables: The database tables can either stored in the ldapdb2 user’shome directory or spread across multiple disk drives using a redirected restore.The disk requirement for the database tables depends upon the IBM LDAPserver version and the number of users in the registry. Note that the followingrequirements are for IBM Tivoli Access Manager (formerly Tivoli SecureWayPolicy Director) users. For regular LDAP users, the disk storage requirementsmay differ.– IBM SecureWay Directory, Version 3.2.1: 20 KB of disk space per user– IBM SecureWay Directory, Version 3.2.2: 11 KB of disk space per user

The requirements on the number of and speed of the CPUs and disk drives on theSecureWay Directory server machine are not within the scope of this document.Many slow servers can perform as well as a single fast server. This type ofplanning is discussed more fully in the IBM Tivoli Access Manager Capacity PlanningGuide. See Technical supplements. One guideline is that faster CPUs improveauthentication and search times, while faster disk drives improve user creation andupdate time.

UNIX operating system tuning for the IBM SecureWayDirectory server

This section describes how to make the operating system changes required tosupport large registries with the IBM SecureWay Directory server. Skip this sectionif the server is to be deployed on a Windows operating system.

Solaris operating systemSkip this section if you are not setting up tuning on the Solaris operating system.

Increase the shared memory maximum (shmmax): The shared memorymaximum must be increased to allow DB2 processes to allocate the buffer poolspace. In a later step, the buffer pool settings may be changed to sizes that are toolarge for the default shared memory maximum.

On a Solaris system, update the shared memory maximum in the /etc/system fileby changing the following line:set shmsys:shminfo_shmmax = physical_memory

where physical_memory is the size of the physical memory on the machine in bytes.After changing the shared memory maximum, reboot the system in order for it totake effect.

Examining the contents of the /etc/system file is not a reliable way to determinethe operating systems setting for the shared memory maximum. For that purpose,use the following command:sysdef | grep –i shmmax

An indication that the shared memory maximum has not been set large enough forthe DB2 cache is the following message:SQL1478W The database has been started but only one buffer pool has been activated.SQLSTATE=01626

An insufficient size for the shared memory maximum can also prevent DB2 fromstarting. In this case, the following message is displayed:SQL1220N The database manager shared memory set cannot be allocated.

Chapter 1. Setting up, managing, and tuning the IBM SecureWay Directory server for Access Manager 3

These messages also appear when executing the following DB2 command:db2 connect to ldapdb2

They also appear when starting the IBM SecureWay Directory server.

Increase process memory size limit: On Solaris, issue the following commands:ulimit -d unlimitedulimit -v unlimited

This sets the process memory size limits to unlimited. At a minimum, set theselimits to 256 MB. If the LDAP cache is to be employed, 256 MB will not likely beenough, so set the memory size to unlimited. Refer to the IBM SecureWayDirectory documentation for more information. See IBM SecureWay Directory.

Increase file size limits: If the file size limits are not high enough, the followingfiles may grow to exceed the limit:v DB2 table and index filesv Temporary files used in the bulk-load process

On Solaris, issue the following command:ulimit -f unlimited

This sets the maximum file size to unlimited.

AIX operating systemSkip this section if you are not setting up tuning on the AIX operating system.

Increase process memory size limit: On AIX, modify the following lines in the/etc/security/limits file:default:data = -1rss = -1

This modification sets the process memory size limits to unlimited. At a minimum,set these limits to 256 MB. If the LDAP cache is to be employed, 256 MB will notlikely be enough memory, so set it to unlimited. Refer to the IBM SecureWayDirectory documentation for more information. See IBM SecureWay Directory.

Refer to Chapter 8, “Process memory size limits” on page 47 for more informationon this subject. It contains information about increasing the number of datasegments that a process can use. The number of data segments that a process canuse is another factor that limits memory usage on the AIX operating system.

Increase file size limits: If the file size limits are not high enough, the followingfiles may expand to exceed the limit:v DB2 table and index filesv Temporary files used in the bulk-load process

On AIX, modify the following lines in the /etc/security/limits file:default:fsize = -1

This modification sets the maximum file size to unlimited.


Create file systems large file enabled: Any file system that is to hold a large filemust be created with large file support enabled. The large file support option isfound in smitty on the ″Add a Journaled File System″ menu.

General IBM SecureWay Directory tuningThis section describes general IBM SecureWay Directory tuning. For the most part,this information is not specific to Access Manager; it is applicable to most uses ofthe IBM SecureWay Directory server. The information is applicable to the initialsetup of an empty database as well as an existing database.

Start the IBM SecureWay Directory server to finish configurationAfter the IBM SecureWay Directory server has been configured, it is necessary tocomplete the database configuration by starting the server. Database tables andindexes are not defined until the first time the server is started. On UNIX systems,start the IBM SecureWay Directory server with the following command:slapd

On Windows systems, start the IBM LDAP server service.

Stop the SecureWay Directory serverOn UNIX systems, use the following commands to stop the IBM SecureWayDirectory Server:ps –ef | grep slapd # find the slapd process idkill slapd process idps –ef | grep slapd # repeat this until slapd is gone

On Windows systems, stop the IBM LDAP server service.

Do DB2 parameter tuningBefore executing the commands in this section, switch to the ldapdb2 user context.On UNIX systems, this can be done with the following command:su – ldapdb2

On Windows systems, run the following command at a command prompt:db2cmdset DB2INSTANCE=ldapdb2

Examples of the commands in this section can be found in the do_tunings_322.shand do_tunings_321.sh scripts. These scripts can be found athttps://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

and in Appendix A, “Scripts” on page 53 to this document.

Execute the following commands to set up several of the DB2 tuning parameters:db2 update database configuration for ldapdb2 using SORTHEAP 2500db2 update database configuration for ldapdb2 using MAXLOCKS 100db2 update database configuration for ldapdb2 using MINCOMMIT 25db2 update database configuration for ldapdb2 using UTIL_HEAP_SZ 5000db2 update database configuration for ldapdb2 using LOGFILSIZ 10000

For IBM SecureWay Directory, Version 3.2.2, use the following commands:db2 connect to ldapdb2db2 alter bufferpool ibmdefaultbp size defaultbp_szdb2 alter bufferpool ldapbp size ldapdb_szdb2 terminate




db2 force applications alldb2stopdb2start

where defaultbp_sz and ldapdb_sz are defined as follows:defaultbp_sz = (phys_mem*0.75)*(0.75)/4096ldapdb_sz = (phys_mem*0.75)*(0.25)/32768

and phys_mem is the amount of physical memory in bytes

For IBM SecureWay Directory, Version 3.2.1, use the following commands:db2 update database configuration for ldapdb2 using BUFFPAGE buffpage_sz

db2 connect to ldapdb2db2 "alter bufferpool ibmdefaultbp size -1"db2 terminate

db2 force applications alldb2stopdb2start

where buffpage_sz is (phys_mem*0.75/4096) and phys_mem is the amount of physicalmemory in bytes. Setting the ibmdefaultbp size to –1 indicates that the size iscontrolled by the BUFFPAGE configuration parameter.

The ibmdefaultbp and ldapbp parameters control the size of DB2 buffer pools. DB2buffer pools hold the DB2 cache of tables and indexes. DB2 uses indexes identifywhich table rows to retrieve during a search.

In the examples, the size calculations are designed to allocate the recommended 75percent of the IBM SecureWay Directory server’s physical memory to the DB2buffer pools. For IBM SecureWay Directory, Version 3.2.2, the calculations dividethe 75 percent of physical memory between the ibmdefaultbp and ldapbp bufferpools in a 3 to 1 ratio. For more information, refer to the IBM Security DirectoryTuning Guide (see IBM SecureWay Directory).

CAUTION:As of the writing of this guide, IBM SecureWay Directory, Version 3.2.2, does notalways perform optimally with large settings for the buffer pool parameters. It isrecommended that the following minimum settings for the buffer pools beinitially used and larger be tried later:db2 alter bufferpool ibmdefaultdp size 49800db2 alter bufferpool ladbp size 400

Error messages: The following message may appear when setting the DB2parameters. They are normal and do not mean there has been a failure.SQL1482W The BUFFPAGE parameter will only be used if one of the buffer poolsis defined with a size of -1.

DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.DB21026I For most configuration parameters, all applications must disconnectfrom this database before the changes become effective

Displaying and verifying the current settings: For IBM SecureWay Directory,Version 3.2.2, the current setting of the DB2 tuning parameters can be displayed byusing the following commands:


db2 get database configuration for ldapdb2 | \egrep ’DBHEAP|SORTHEAP|MAXLOCKS|MINCOMMIT|UTIL_HEAP_SZ’

db2 connect to ldapdb2db2 "select bpname,npages,pagesize from syscat.bufferpools"db2 terminate

For IBM SecureWay Directory 3.2.1, the current setting of the DB2 tuningparameters can be displayed by using the following commands:db2 get database configuration for ldapdb2 | \egrep ’BUFFPAGE|DBHEAP|SORTHEAP|MAXLOCKS|MINCOMMIT|UTIL_HEAP_SZ’

db2 connect to ldapdb2db2 "select * from syscat.bufferpools"db2 terminate

In this second case, verify that the NPAGES column is defined as -1. If not, redothe DB2 parameter tunings.

Functional problems can occur if one of the heap configuration parameters is toolow. To display the current heap parameter settings issue the following DB2command:db2 get db cfg for ldapdb2 | grep HEAP

The following is an example output showing the minimum values for the variousheap parameters:Database heap (4KB) (DBHEAP) = 1200Utilities heap size (4KB) (UTIL_HEAP_SZ) = 5000Max appl. control heap size (4KB) (APP_CTL_HEAP_SZ) = 128Sort list heap (4KB) (SORTHEAP) = 2500SQL statement heap (4KB) (STMTHEAP) = 2048Default application heap (4KB) (APPLHEAPSZ) = 2048Statistics heap size (4KB ) (STAT_HEAP_SZ) = 4384

If a heap parameter is less that the minimum, increase it to the minimum using acommand similar to the following:db2 update db cfg for ldapdb2 using parm_name parm_value

where parm_name is the name on the third to last column of the above output,without the parenthesis and the parm_value is the value for that parameter in givenin the last column.

If the heap parameters are set too low, the IBM SecureWay Directory will fail invarious functional ways that may not indicate a problem with the heap parameter.The cli.error file (/var/slapd/cli.error on Solaris and /tmp/cli.error on AIX.)is useful in these situations. It contains DB2 error messages that often indicatewhich heap parameter is too low.

db2look is a useful DB2 utility that for most cases is an alternative to the abovecommands. It provides considerable information about the database and itsconfiguration in one command. Here is an example of its usage:db2look -d ldapdb2 -u ldapdb2 –p –o outpu_file

where output_file is a file location for storing the results.

Warning about tuning while slapd is running: Note that the DB2 parametertuning commands make use of db2 terminate. If the IBM SecureWay Directoryserver process, slapd, is running when this command is issued, it renders the


server partially functional. Any cached searches appear to respond correctly. Othersearches may simply return with no results or error messages or the operationserror message may appear. The recovery is to recycle the IBM SecureWay Directoryserver. It is best to stop the IBM SecureWay Directory server when changing theDB2 tuning parameters.

Buffer pool memory usage warnings: If any of the buffer pools are set too high,DB2 can fail to start due to insufficient memory. If this occurs there may be a coredump file, but usually there is no error message.

On AIX systems, the system error log may report a memory allocation failure. Thislog can be viewed by executing the following command:errpt –a | more

Restoring a database that was backed up on a system with buffer pool sizes thatare too large for the target machine may cause the restore to fail. Refer toChapter 9, “Troubleshooting” for information on how to work around thisproblem.

If the DB2 fails to start due to buffer pool sizes being too large, redo the DB2tuning parameters.

Check for missing and extra indexesRun the check_indexes.sh, which is found online athttps://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

(and in Appendix A, “Scripts” on page 53 of this guide) under the context of theldapdb2 users. Enter this context on UNIX systems with the following command:su – ldapdb2

On Windows systems, run the following command at a command prompt:db2cmdset DB2INSTANCE=ldapdb2

In rare cases, the IBM LDAP server can drop one or more of its DB2 table indexes.Since DB2 table indexes are critical to IBM LDAP server performance, they shouldbe checked.

The check_indexes.sh script checks for the existence of DB2 table indexes that areimported for IBM LDAP server and Access Manager performance. The scriptassumes that it is being used against an ldapdb2 database that Access Manager hasbeen configured into it. If Access Manager has not been configured into thedatabase, the script reports several missing indexes.

The script prints out a suggested DB2 create command for any missing indexes. Itprints out a colon-separated index definition when it finds indexes that are notexpected. These unexpected indexes could come from other products using LDAP,so are more for informational purposes. The second field of the colon-separated listof extra indexes is the name of the index. If the unexpected indexes are notdesired, they can be deleted using the following command:db2 drop index index_name

db2look is a useful utility that also displays information about database indexes.Here is an example of its usage:db2look -d ldapdb2 -u ldapdb2 –p –o output_file




where output_file is the location for file for storing the results.

Do a DB2 reorgchkTo perform a DB2 reorgchk on UNIX systems, use the following command:su – ldapdb2db2 connect to ldapdb2db2 reorgchk update statistics on table alldb2 terminate

To perform a DB2 reorgchk on Windows systems, use the following command:db2cmdset DB2INSTANCE=ldapdb2db2 reorgchk update statistics on table alldb2 terminate

Start the IBM SecureWay Directory serverStart the IBM SecureWay Directory server to verify that the DB2 tuning parametersdo not cause functional problems. On UNIX systems, run the following commands:slapdiostat 5 # or vmstat, repeat this until CPU utilization goes idle

On Windows systems, start the IBM LDAP service.

Verify change log is not configuredThe IBM SecureWay Directory Change Log significantly slows down updateperformance. The change log causes all Directory updates to be recorded in aseparate Change Log DB2 database, separate from the Directory server database.The change log database can be used by other applications to track updates. AccessManager does not use the change log functionality.

The change log configuration can be determined by searching for theCN=CHANGELOG pseudo suffix as follows:ldapsearch -h ldap_host -D cn=root -w ldap_passwd -s base -b "objectclass=*" | \grep "CN=CHANGELOG"

where ldap_passwd is the password for the directory administrator.

To verify that the IBM SecureWay Directory Change Log option is not configured,attempt to unconfigure it as follows:ldapucfg -g

The following message should appear:The Change Log is not currently enabled.

Tuning slapd32.confThe following sections discuss changes to the /etc/slapd32.conf file. On Windowssystems, the etc/slapd32.conf file is not located at the root of the disk drive.Search each disk to find it.

Increase the number of SecureWay Directory connections to DB2: Edit the/etc/slapd32.conf file and increase the ibm-slapdDbConnections parameter to 8for AIX or 30 for all other operating systems.

The number of DB2 connections determines the amount of processing concurrencybetween the IBM SecureWay Directory server and DB2. If the number of DB2connections is increased beyond its maximum value, the maximum will be used.


Turn off object class alias checking: Edit the /etc/slapd32.conf file and add thefollowing line:ibm-slapdSetEnv: OC_ALIAS=NO

Add the line under the cn=Front End,cn=Configuration DN. Here is an example:dn: cn=Front End,cn=Configurationobjectclass: topobjectclass: ibm-slapdFrontEndibm-slapdSetEnv: OC_ALIAS=NO

This option turns off object class aliasing, whereby the IBM SecureWay Directoryserver searches the Directory database for the numeric alias for object classes. Thisonly occurs when object class is specified in the LDAP search filter. The object classalias search causes the DB2 optimizer to make poor choices regarding indexing andsearch performance degrades significantly. Search performance does not degrade ifyou turn off aliasing. This option is only available on IBM SecureWay Directory,Version 3.2.2, and above.

Enable the IBM SecureWay Directory concurrent read/write capability: Edit the/etc/slapd32.conf file and add the following line:ibm-slapdSetEnv: LDAP_CONCURRENTRW=ON

Add the line under the cn=Front End,cn=Configuration DN. Here is an example:dn: cn=Front End,cn=Configurationobjectclass: topobjectclass: ibm-slapdFrontEndibm-slapdSetEnv: LDAP_CONCURRENTRW=ON

LDAP_CONCURRENTRW controls the concurrency of the read and writeoperations. Read operations are also called searches and write operations are calledupdates. Without LDAP_CONCURRENTRW, the IBM SecureWay Directory serverserializes read operations with write operations. With LDAP_CONCURRENTRW,read operations occur concurrently with write operations. WithLDAP_CONCURRENTRW, there is a slight chance of erroneous results when aread is performed on data that is being updated. From an Access Manager point ofview, an example is a failed authentication for a user that is in the process of beingcreated.

The LDAP_CONCURRENTRW parameter can also be set as an environmentvariable in the process where the IBM SecureWay Directory server is started. Forexample, as follows:kill slapd process idexport LDAP_CONCURRENTRW=ONslapd

Add suffix information to slapd32.conf: If you have not already done so, forexample, because the database already exists, add suffix-distinguished names(DNs) to the /etc/slapd32.conf file. Preferably, add only one suffix for all userdirectory objects. Add another suffix for the Access Manager secauthority=defaultobject. This is required to configure Access Manager. Here are some example lines:ibm-slapdSuffix: secauthority=defaultibm-slapdSuffix: user suffix

where user suffix is the suffix to be used for user objects. Place these lines next toexisting ibm-slapdSuffix lines in the file and order them as indicated in the nextsection.


You should use only one suffix for user objects. The user name space can bebroken up within the suffix by using multiple directory container objects. If morethan one suffix is used, additional directory searches are necessary to find the userobject, which slows down performance. For one or two additional suffixes, theperformance slows down by approximately 10 percent. Refer to the IBMSecureWay Directory documentation for more information on suffixes. See IBMSecureWay Directory.

Order the suffixes in slapd32.conf: After the set of suffixes to be added has beendetermined, order them in the /etc/slapd32.conf file for best performance. Listthe least commonly used suffixes first and the most commonly used suffixes last.For example, list the suffix with the most number of users last. Access Managersearches each suffix until it finds the user it is authenticating. It does this in thereverse order in which the suffixes are listed in the /etc/slapd32.conf file.

Typically, users are not stored in the Access Manager secauthority=default suffix. Inthis case, list the secauthority=default suffix first.

Recycle the IBM SecureWay Directory server: Recycle the IBM SecureWayDirectory server to make it aware of any changes made so far, for example, anynew suffixes added. The following is a summary of how this is done on UNIXsystems:ps –ef | grep slapd # find the slapd process idkill slapd process idps –ef | grep slapd # repeat this until slapd is goneslapd iostat 5 # or vmstat, Repeat this until CPU utilization goes idle

On Windows systems, stop and start the IBM LDAP service.

Verify suffix order: Verify that the suffixes are ordered for performance byissuing the following command:ldapsearch -h ldap_host -D cn=root -w ldap_passwd \-s base -b "" "objectclass=*" | grep namingcontexts

The suffixes will be listed in the reverse order in which they exist in the/etc/slapd32.conf file. Ignore the pseudo suffixes cn=schema and cn=localhost.

Create the suffix objectsSkip this step if the directory is to be restored from a backup. A replica server istypically loaded from a backup copy of the master Directory server. The IBMSecureWay Directory db2ldif and ldif2db utilities or DB2 backup and restoreutilities can be used for these purposes.

If you have not already done so, create the IBM SecureWay Directory objects for allsuffixes, except the Access Manager secauthority=default suffix. The following is anexample of creating a suffix object named o=ibm.com using the IBM SecureWayDirectory ldapadd command and an LDIF-encoded definition of that suffix object.cat <EOF | ldapadd -h ldap_host -D cn=root -w ldap_passwddn: o=ibm.comobjectClass: organizationobjectclass: topo: ibm.comEOF

where ldap_host is the host name of the directory server and ldap_passwd is the IBMSecureWay Directory administrator’s password.


Note that this example does not assign any access control lists (ACLs) to the suffixobject. Any ACL can be assigned, but be aware that Access Manager will add itsown ACLs to these objects and enable ACL propagation. Access Manager makesthese ACL changes to allow its servers to access all objects in the directory tree. Ifan ACL design is chosen that conflicts with Access Manager’s ACL model, AccessManager will not be able operate on the affected user objects.

Access-Manager-Specific SecureWay Directory set upThe following sections describe the IBM SecureWay Directory set up in moredetail. Although similar steps must be performed in any configuration of the IBMSecureWay Directory, the information provided here is specific to Access Manager.

Add the Access Manager schema to the SecureWay DirectoryserverIn order to add Access Manager objects to the IBM SecureWay Directory server, theAccess Manager schema must be added to the IBM SecureWay Directory. Executethe following ldapadd command to accomplish this task:ldapadd -h ldap_host -D cn=root -w ldap_passwd -f secschema.def

The secschema.def file can be found either in the /opt/PolicyDirector/etcdirectory on a machine with the Access Manager installed or with the scriptslocated at https://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

If a previous version of the Access Manager schema has already been added to theIBM SecureWay Directory server, a different schema definition file should be usedto upgrade the schema, instead of adding it. Refer to the IBM Tivoli Access ManagerBase Installation Guide for more information. See “Base information” on page vii.

Create a minimum, unconfigured Access Manager SecureWay Directory objectspace: Skip this step if the directory is to be restored from a backup. Replicaservers are typically set up this way.

If Access Manager has never been configured into the IBM SecureWay Directoryserver, create the directory objects for a minimum, unconfigured Access Managerregistry. These objects include container objects needed to hold users and groups.Configuring the Access Manager management server into the IBM SecureWayDirectory server is the standard way of providing these objects. It is oftenconvenient not to configure Access Manager in order to complete the set up of aDirectory server. For that reason, this information is provided.

Add the Access Manager objects to the IBM SecureWay Directory server using thefollowing ldapadd command:ldapadd -h ldap_host -D cn=root ldap_passwd -f pd_clean_nousers.ldif

where pd_clean_nousers.ldif is the name of the file containing the LDIF input fordefining the Access Manager objects. This file can be found with the scripts locatedat: https://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

Add Access Manager ACLs to all suffix objectsPerform this step if new suffixes are added and Access Manager is alreadyconfigured into the Directory server. Skip this step if the directory server is to berestored from a backup or Access Manager is to be configured into it before usersare added. A replica server is typically restored from a backup.






Add Access Manager ACLs to all suffix objects. One way of doing this is to use thecheck_ldap_acls.sh script provided in the scripts located online athttps://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

and in Appendix A, “Scripts” on page 53 of this guide. This script can be rununder the context of any user. The following is an example of how it is run:check_ldap_acls.sh ldap_host ldap_passwd | \ldapadd -h ldap_host -D cn=root -w ldap_passwd

where ldap_host is the host name of the directory and ldap_passwd is the IBMSecureWay Directory administrator’s password. The check_ldap_acls.sh script canbe found online athttps://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

and in Appendix A, “Scripts” on page 53 of this guide. This script duplicates whatAccess Manager does to suffix objects when it configures into an IBM SecureWayDirectory server.

The script modifies all suffix objects to enable ACL propagation and allows AccessManager servers to access all objects of the directory tree. Here is an example of ahypothetical suffix object after modifications:dn: o=ibm.comobjectClass: organizationobjectclass: topo: ibm.comaclpropagate: TRUEaclentry: group:CN=IVACLD-SERVERS,

CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:normal:rsc

aclentry: group:CN=REMOTE-ACL-USERS,CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:normal:rsc

aclentry: group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULT:object:ad:normal:rwsc:sensitive:rwsc:critical:rwsc

Preparing to expand to a large registryThis section explains how to prepare an existing registry for the loading of manyusers. If the registry has not been tuned, review “UNIX operating system tuningfor the IBM SecureWay Directory server” on page 3 before continuing.

If tuning an existing registry or the registry will fit on the existing file system ordisk, skip this section.

Stop the SecureWay Directory serverStop the IBM SecureWay Directory server using the following commands:ps –ef | grep slapd # find the slapd process idkill slapd process idps –ef | grep slapd # repeat this until slapd is gone

Force all DB2 Connections to be closedSwitch to the ldapdb2 user and run the following command:db2 force applications all






Backing up the databaseIf you are are configuring a replica server from a backup of the master server, skipthis part of the procedure.1. Execute DB2 backup command similar to the following example:

db2 backup db ldapdb2 to [file system | tape device]

2. When the database has been backed up successfully, you will see a messagesimilar to:Backup successful. The timestamp for this backup image is : 2000042020405

Note: Make sure that the backup is successful before proceeding. The next stepdestroys the existing database in order to recreate it. If the backup was notsuccessful, the existing database is lost. It should not be necessary, but itmight be a good idea to verify the success of the backup by restoring to aseparate machine.

Do a redirected restore to distribute the database across multipledisk drivesAssuming that the database will not fit on a single disk, do a redirected restore todistribute it among multiple disks.

Create clean directories on the disks to be used. For IBM SecureWay Directory,Version 3.2.2, create two directories on each disk, one for the user tablespace (2)and the other for the LDAP tablespace (3). For Version 3.2.1, just create onedirectory for the user tablespace (2).

Do not use the root of a file system, such as one with the lost+found file. Makesure the directories can be written to by the ldapdb2 users

Start the restore with a command similar to this example:db2 restore db ldapdb2 from [location of backup] replace existing redirect

The above command prepares for the restore, but does not actually do the restore.It returns with a message indicating that the restore was complete, but is waitingfor the next step. The next step is to define the DB2 tablespace containers. For IBMSecureWay Directory, Version 3.2.2, use commands similar to:db2 "set tablespace containers for 2 using \(path ’/dir 1’, path ’/dir 2’, ..., \dpath ’dir n’)’

db2 "set tablespace containers for 3 using \(path ’/dir’ path ’/dir 2’,..., \dpath ’/dir n’)"

For IBM SecureWay Directory, Version 3.2.1, use commands similar to:db2 "set tablespace containers for 2 using \(path ’ /dir 1’, path ’dir 2’, ..., dpath ’dir n’)"

After, the tablespaces are defined, continue the restore with the followingcommand:db2 restore db ldapdb2 continue

Refer to ″Distributing the database across multiple physical disks″ for moreinformation.“Distributing the database across multiple physical disks” on page 34


Note: If the database was restored from a backup, as in the case of setting up areplica server, skip the following section and go directly to “Tuning after alarge number of updates” on page 16.

Adding users and groupsThis section explains how to add users and groups to an already-tuned the IBMSecureWay Directory server. If setting up a replica server or if tuning an existingserver, skip the steps in this section. Skip this section if tuning an existing registry.

Do the load of users or groupsFor loading a large number of users (more than 10,000), the bulkload utility isrecommended. Refer to the “The LDAP bulkload utility” on page 40 for moreinformation. For loading fewer than 10,000, the Access Manager pdadmincommand or the IBM SecureWay Directory ldapadd or ldif2db utilities provideacceptable performance.

For adding a large number of members to a group , use the group add scriptsdescribed in “Adding a large number of members to a group” on page 44 Foradding fewer than 10,000 users to a group, you can obtain acceptable performanceby using the Access Manager pdadmin command.

Add Access Manager ACLs not created by the bulkload utilityTo add Access Manager ACLs not created by the bulkload utility, run thefixacls.sh script, as follows:su – ldapdb2fixacls.sh

For Windows systems, run the script as follows:db2cmdset DB2INSTANCE=ldapdb2fixacls.sh

This script should be run after the IBM SecureWay Directory bulkload utility hasbeen run to create Access Manager users. Because creating ACLs with the bulkloadutility is a very slow process, you should run bulkload with ACL supportdisabled. The fixacls.sh script adds the missing ACLs that are not created by thebulkload utility.

The script asks for a suffix object from which LDAP users will inherit their ACLs.A good choice is the suffix into which the users are loaded. Even though usersmay be loaded into different suffixes in the same bulk load execution, only onesuffix can be chosen. If you want to employ a different ACL model, either loadusers into one suffix at a time or modify the script to have the desired effect.

This step can be skipped if some utility other than bulkload is used to create theusers in the Directory or if ACLs are not necessary, such as in the case where theDirectory server is to be accessed only by the LDAP administrator.

Refer to the bulk load section for more information on using the LDAP bulkloadutility. See “The LDAP bulkload utility” on page 40. Refer to Chapter 6, “AccessManager’s Use of LDAP Directory” on page 31 for more information on howAccess Manager uses LDAP ACLs.


The fixacls.sh script has no effect if it is run a second time. If you make a wrongchoice for ACL inheritance on the first use, use fixacls2.sh to make corrections.The fixacls2.sh script takes longer to run because it updates the ACL on everyobject in the directory, except suffix objects. It does this, even if the ACL alreadyexists and does not need to be updated.

Note that, in some environments, it might not be desirable to assign the same setof ACLs to all objects in the directory. For example, it might be desirable to assignACLs differently based upon the subtrees within the directory. For this purpose,use the fixacls3.sh script, which takes two inputs:v subtree DN: the root of the subtree to be updatedv ACL source DN: the DN of an object from which the subtree takes its ACL source

Note that these utilities are only needed when the bulkload utility has been usedto load the directory. They might be helpful in situations where mass ACL changesare necessary.

These scripts can be found online athttps://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

and in Appendix A, “Scripts” on page 53 of this guide.

Do the tunings in the next section titled ″Tuning after a LargeNumber of Updates″

Do a DB2 BackupExecute the backup utility of choice, for example:su – ldapdb2db2 backup db ldapdb2 to [file system | tape device]

or alternatively use the IBM SecureWay db2ldif utility.

Tuning after a large number of updatesAfter a large number of updates, such as following updates completed using thebulkload utility, you should perform the tunings discussed in this section. Thesetunings should also be performed if they have never been performed.

Redo the DB2 tuning parametersRefer to “Do DB2 parameter tuning” on page 5. The DB2 tuning parameters mightnot be different from the last time they were set, but it is a good idea to checkthem. The DB2 tuning parameters might change as a result of the bulk loadprocess or the db2 restore command. DB2 tuning parameters are restored to theirbacked-up values when you run the db2 restore.

Recheck for missing and extra indexesSwitch to the ldapdb2 user and run the check_indexes.sh script.

Refer to “Check for missing and extra indexes” on page 8 for more information.

Do a DB2 reorgchkTo perform a DB2 reorgchk on UNIX, run the following commands:




su – ldapdb2db2 connect to ldapdb2db2 reorgchk update statistics on table alldb2 terminate

To perform a DB2 reorgchk on Windows, run the following commands:db2cmdset DB2INSTANCE=ldapdb2db2 connect to ldapdb2db2 reorgchk update statistics on table alldb2 terminate

DB2 reorgchk is one of the most important and often overlooked DB2 tuningcommands. As updates are performed on the DB2 database, the DB2 optimizermay start making poor choices for use of indexes. The reorgchk can fix thissituation. The reorgchk command is often overlooked because it is not a one-timetuning item. It is recommended that the reorgchk command be repeated afterevery 10,000 updates.

Before running the reorgchk command, you should stop the IBM LDAP server toprevent any DB2 queries or updates from occurring while the command is inprogress. Although this is optional, database queries and updates will be very slowand may time out.

It takes about 20 minutes to do a reogrchk command on a 400 MHz Solarismachine with three million users.

Note that the performance benefit from running the reorgchk command isimmediate. It is not necessary to restart DB2 following a reorgchk command.

In addition to improving performance, the reorgchk command reports statistics onall of the tables and indexes in the database. Note that the reorgchk command alsoreports statistics on the organization of DB2 tables.

Do a DB2 runstats on the objectclass tableFor registry sizes of more than three million users, run the DB2 runstats commandon the object class table as follows:su – ldapdb2db2 connect to ldapdb2db2 runstats on table ldapdb2.objectclass with distribution and \detailed indexes all shrlevel referencedb2 terminate

On Windows systems, run the following commands:db2cmdset DB2INSTANCE=ldapdb2db2 connect to ldapdb2db2 runstats on table ldapdb2.objectclass with distribution and \detailed indexes all shrlevel referencedb2 terminate

This command improves the Directory server startup time.

Do not perform updates while the runstats command is in progress. This includescertain Access Manager pdadmin commands, like those for creating and deletingusers and groups. Updates are blocked until the completion of the runstatscommand.


This concern does not apply to LDAP searches. LDAP searches are not blocked bythe runstats command. There is only a slight degradation in search performancewhile the runstats command is in progress. For example, Access Managerauthentications are not affected by the progress of runstats command.

It takes about 10 minutes to do a runstats command for the objectclass table on a400 MHz Solaris machine with three million users. Without the runstats command,a database of five million users takes about 15 minutes to start the IBM SecureWayDirectory server. After the runstats command, it takes less than a minute.

If the runstats command fails with the following message:SQL2310N The utility could not generate statistics. Error "-1024" was returned

then a connection does not exist with the ldapdb2 database. Make sure to rundb2 connect to ldapdb2

and retry.

Note that the performance benefit from running the runstats command isimmediate. It is not necessary to restart DB2 following a runstats command.

Do DB2 statistics tuningAfter any reorgchk or runstats command, execute the sysstat_tune.sh script asfollows:su – ldapdb2sysstat_tune.sh

For Windows systems, run the following commands:db2cmdset DB2INSTANCE=ldapdb2sysstat_tune.sh

This script updates certain DB2 statistics such that the DB2 optimizer makesefficient choices on Directory searches. These updates are undone by the reorgchkor runstats utilities. The sysstat_tune.sh script can be found online athttps://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

and in Appendix A, “Scripts” on page 53 of this guide.

Start the IBM SecureWay Directory serverOn UNIX systems, execute the following command:slapd

On Windows systems, start the LDAP service.

Test the performance of the registryThe test_registry_perf.sh performs Directory searches similar to the searchesperformed by Access Manager. Execute the following script under the context ofany user to verify Directory searches perform with sub-second performance:test_registry_perf.sh ldap_host ldap_admin_pwd user_suffix \test_user test_user_password




where ldap_host is the hostname of the Directory server, ldap_admin_pwd is theDirectory server (cn=root) admin’s password, user_suffix is a suffix containing auser to be tested, test_user and test_user_password are the principal name andpassword of the user to be tested.


Chapter 2. Special case IBM LDAP directory tunings

This section contains tunings that are not normally recommended; however, butthere may be some environments where these tunings are useful.

Using LDAP cacheThe LDAP cache is more efficient in memory usage and speedier than the DB2cache, yet not as efficient as the Access Manager credential cache. Disadvantages tothe LDAP cache are that it becomes invalidated on most update operations andcan take a long time to load. The environments that gain most from LDAP cachingare those with small registry sizes and few updates.

Keep in mind that increasing the LDAP cache size can cause the slapd processmemory size to exceed system limits. For information about increasing these limits,see Chapter 8, “Process memory size limits” on page 47.

Setting the LDAP cache parametersThe LDAP cache parameters that are recommended for use with Access Managerare RDBM_CACHE_SIZE and RDBM_FCACHE_SIZE. These parameters aredefined to LDAP with environment variables. To define LDAP cache environmentvariables, do either of the following:v To define the LDAP cache environment variables in the command shell (before

starting slapd), run the following commands:stop LDAP (slapd process)export RDBM_CACHE_SIZE=<value>export RDBM_FCACHE_SIZE=<value>start LDAP (slapd process)

v To define the LDAP cache environment variables in the slap32.conf file, add thefollowing entries to the file as follows:dn: cn=Front End,cn=Configurationobjectclass: topobjectclass: ibm-slapdFrontEndibm-slapdSetEnv: RDBM_CACHE_SIZE=<value>ibm-slapdSetEnv: RDBM_FCACHE_SIZE=<value>

For information on the definition of these and other LDAP cache parameters, seethe IBM SecureWay Directory documentation (“IBM SecureWay Directory” on pageix).

Choosing the LDAP cache values for Access ManagerThe primarily use of the LDAP cache is for caching authenticated users. There area couple of ways to choose values for the LDAP cache parameters. One is to basethe choice on the number of users to be cached. Another is to base the choice onthe amount of memory available for caching. Both ways require information on thememory usage per cached user and the number of cache entries used per cacheduser.

For Access Manager, the memory usage per cached user is approximately 3 KB andthe number of cache entries used (per cached user) is four for the entry cache andfive for the filter cache. The entry cache is controlled by RDBM_CACHE_SIZE and


the filter cache is controlled by RDBM_FCACHE_SIZE. These approximations varygreatly with the various Access Manager configuration settings and usage.

The following items affect Access Manager’s use of LDAP cache resources:v User-and-group-in-same-suffix setting in the webseald.conf filev Default-policy-override-support setting in the webseald.conf filev Ordering and number of LDAP suffixes in the /etc/slapd32.conf filev Authenticating through GSO junctionsv Whether the user was created using Version 3.7 or Version 3.8 of IBM Tivoli

SecureWay Policy Director. Related to this is the usage of the PD38_SCHEMA_OFFenvironment variable.

Note: An LDAP registry containing users that were created using a version ofPolicy Director earlier than Version 3.8 does not immediately benefit fromthe LDAP cache. The reason for this is that Access Manager performs anautomatic migration of pre-Version 3.8 users to the new attributesintroduced in Policy Director, Version 3.9. This automatic migration causesupdates to LDAP that invalidate or remove users from the cache. Forinformation about the PD38_SCHEMA_OFF parameter and turning offautomatic migration, see“Automatic migration of IBM SecureWay PolicyDirectory 3.7 users during authentication” on page 27.

Choosing cache values based on the number of users to becreatedUse the following formulas for choosing the LDAP cache settings:LDAP entry cache size = (number of AM users) * 4LDAP filter cache size = (number of AM users) * 5Memory requirements = (number of AM users) * 3 KB

Choosing cache values based on the amount of memoryavailable for cachingUse the following formulas for choosing the LDAP cache settings:number of AM users cached = desired memory usage / 3 KBLDAP cache size = (number of AM users) * 4LDAP filter cache size = (number of AM users) * 5

Example cache size settingsThe following table provides guidelines for cache size settings. Because thesesettings might not apply in every case, make certain to verify them (as explainedin the following section).

Table 1. Cache Size Settings

Number of AMUsers

Entry CacheSize

Filter CacheSize

Memory Usage Additional DataSegments Needed

(AIX)

10,000 40000 50000 30 MB 0

50,000 200000 250000 150 MB 0

100,000 400000 500000 300 MB 1

Verifying the LDAP cache resources usageTypically, there are two things to verify regarding the LDAP cache settings. One iswhether cache misses have been eliminated and another is if the LDAP processmemory usage is as expected.


To verify that cache misses have been eliminated, issue the following commandsperiodically while LDAP searches are in progress:ldapsearch –h ldap_host -s base –b ’cn=monitor’ ’objectclass=*’ | \grep entry_cache_miss

If all results come from the LDAP cache, the entry_cache_miss count remainsconstant throughout the usage of LDAP.

To verify that the LDAP cache memory usage is as expected, monitor the processmemory growth as users are cached. The UNIX ps utility is recommended. Forexample, the following ps command shows the current memory size of the LDAPprocess:ps –e –o vsz –o –comm | grep slapd

Repeat this command periodically to determine what at what memory size theslapd process is when it levels off.

To verify that the LDAP cache memory usage does not exceed process memorysize limits, watch the slapd process and verify that it does not end unexpectedly. Ifthe slapd process ends after increasing the LDAP cache, it is probably because ithas exceeded the memory limits.

Chapter 2. Special case IBM LDAP directory tunings 23

Chapter 3. Tuning IBM Tivoli Access Manager WebSEAL

The following sections provide tuning information for Access Manager.

Recommended Access Manager WebSEAL tunings

auth-using-compareThe default setting for the auth-using-compare option in the/opt/pdweb/etc/webseald.conf file is yes. This setting is recommended.Authentication performance is 25- to 30-percent slower when auth-using-compareis set to no than when it is set to yes.

With auth-using-compare set to no, Access Manager authenticates using thetraditional LDAP bind and unbind commands. With auth-using-compare set toyes, Access Manager authenticates with the IBM LDAP unique search and comparecommand. The auth-using-compare option is ignored when the iPlanet DirectoryServer is used.

user-and-group-in-same-suffixThe default setting for the user-and-group-in-same-suffix option in the/opt/pdweb/etc/webseald.conf file is no. If possible, you should set this option setto yes. When it is set to yes, Access Manager assumes the user, and the group orgroups the user is a member of, are in the same suffix. When it is set to no, AccessManager searches every suffix for a given user’s group membership.

The performance benefit from setting user-and-group-in-the-same-suffix toyes isreduced LDAP searches for authentication. Authentication performance is directlyrelated to the number of LDAP search operations that are performed.

default-policy-override-supportThe default setting for the default-policy-override-support option in the/opt/pdweb/etc/webseald.conf file is no. You should set this option to yes, ifpossible. When it is set to yes, Access Manager does not search the LDAP directoryfor personal policy overrides when authenticating a user. If a personal policyoverride exists for a user, it is ignored. Instead, the global policy applies to allusers. When it is set to no, Access Manager searches the LDAP directory for policyoverrides and typically does not find them.

The performance benefit from setting default-policy-override-support to yes is onefewer LDAP search during authentication. Authentication performance is directlyrelated to the number of LDAP search operations that are performed.


Chapter 4. Special case IBM Tivoli Access Manager WebSEALtunings

LDAP admin account (cn=root)When Access Manager is configured, it creates LDAP user accounts that are usedto access the LDAP directory. The LDAP server administrator can set ACLs in thedirectory that allow or deny Access Manager server users access to parts of thedirectory tree. For the IBM SecureWay Directory server, the additional ACLchecking associated with each LDAP search results in a slight performancereduction of approximately 10 percent.

The IBM SecureWay Directory server does not perform ACL checking when theaccount that is used to access the directory is that of the LDAP root administrator.By changing the Access Manager configuration to use the LDAP rootadministrator’s account, ACL checking is eliminated. This is usually the cn=rootaccount.

The options that control this are bind-dn and bind-pwd in the/opt/PolicyDirector/etc/ivmgrd.conf and /opt/pdweb/etc/webseald.conf files.

Load balancing between LDAP replicasAccess Manager can balance its authentication load between multiple LDAPservers. In environments where the LDAP server is the bottleneck, each additionalLDAP server results in a linear improvement to authentication performance.

Note: Authentication performance also depends on the authentication loadthroughput of the Access Manager WebSEAL servers and the junctionedback-end Web servers (if they are used).

The performance improvement for adding an LDAP server is apparent only if theLDAP server is the bottleneck.

The /opt/PolicyDirector/etc/ldap.conf file controls the definition of the LDAPserver (or servers) for use during authentication.

SSL between IBM Tivoli Access Manager and LDAPThe communication protocol between Access Manager and LDAP can be eitherTransmission Control Protocol (TCP) or Secure Sockets Layer (SSL). Because trafficbetween Access Manager and LDAP is light in comparison to HTTP/HTTPS trafficand because communication is over a static SSL session, the performance differencebetween using TCP and SSL is approximately 10 percent.

Automatic migration of IBM SecureWay Policy Directory 3.7 usersduring authentication

IBM SecureWay Policy Director, Version 3.8, provided a more efficient organizationof LDAP attributes among Policy Director user objects than previous versions. Thiswas enabled through the use of a new schema in Version 3.8. The efficiency gain isin the number of operations required to perform authentication. This results in


improved authentication performance. For more information on the post-Version3.8 organization of attributes among LDAP objects, see Chapter 6, “AccessManager’s Use of LDAP Directory” on page 31.

If users are created on a version of Policy Director earlier than Version 3.8, AccessManager automatically migrates those users to the post-Version 3.8 schemadefinitions during authentication. This results in updates to LDAP and can resultin reduced performance. In many cases, automatic migration is not even noticed.

If performance problems are seen when authenticating users created using anearlier version of Access Manager, automatic migration might be the cause. To turnoff automatic migration, set the PD38_SCHEMA_OFF environment variable. Forexample, to define the PD38_SCHEMA_OFF environment variable before startingAccess Manager, enter the following commands:export PD38_SCHEMA_OFF=1pd_start start

This environment variable can be set to any value. Only the existence of thevariable is required.

SSL session cache, user credential cache, and memory useThe following parameters in the /opt/pdweb/etc/webseald.conf file are relevant tothese caches:[ssl]ssl-v2-timeout = 100ssl-v3-timeout = 7200ssl-max-entries = 4096[session]max-entries = 4096timeout = 3600inactive-timeout = 600

The ssl-max-entries and max-entries options control the size of the SSL and credentialcaches, respectively.

Increases to the SSL and credential cache sizes can cause the WebSEAL processmemory usage to exceed system limits. For information about increasing theselimits, see Chapter 8, “Process memory size limits” on page 47.

The SSL session cache uses about 250 bytes of process memory per entry and thecredential cache uses about 7.5 KB of process memory per entry.

The previous numbers are for AIX. On Solaris, the combined SSL session cache andcredential caches use about 5.6 KB per entry. It is probably sufficient to consider anaverage of about 7 KB per entry.


Chapter 5. Tuning the AIX operating system for IBM TivoliAccess Manager and LDAP

Define the following environment variables in the command shell when startingIBM Tivoli Access Manager servers:v SPINLOOPTIME=650 (for SMP machines)v MALLOCMULTIHEAP=1 (for SMP machines)v AIXTHREAD_MUTEX_DEBUG=OFFv AIXTHREAD_SCOPE=S

Define the following environment variables in the command shell when startingthe LDAP server:v SPINLOOPTIME=650 (for SMP machines)v MALLOCMULTIHEAP=1 (for SMP machines)


Chapter 6. Access Manager’s Use of LDAP Directory

Suffix: c=us Perf hint: define only 2 suffixes Suffix: secAuthority=Default

dn:cn=JoeSmith,...,c=usobjectclass:inetOrgPersonobjectclass:ePersonobjectclass:organzationalPersonobjectclass:personobjectclass:topcnLJoeSmithsn:Smithuserpassword:{iMASuid:anything

dn:secAuthority=Defaultcn=JopeSmith,...,c=us

objectclass:secUserobjectclass:eUserobjectclass:cimManagedElementobjectclass:topsecauthority:Defaultseclogintype:Default:LDAPprincipalname:jsmithsecpwdvalid:truesecacctvalid:truesecuuid:f80dc9f8-488c-11d4-98cf-0004ac5e5097sechaspolicy=falsesecwdlastchanged:20000622223220.0Z

dn:secUUID=f80dc9f8-488c-11d4-98c-0004ac5e5097cn=Users,secAuthority=Default

objectclass:secMapobjectclass:topsecdn:JoeSmith,...,c=ussecuuid:f80dc9f8-488c11d4-98cf0004ac5e5097

dn:cn=PolicyData,secAuthority=Default,cn=JoeSmith,...,c=usobjectclass:secPolicyDataobjectclass:topcn:PolicyDatasecpwdlastchanged:2000062223220.0Z

New in PD 3.8

dn:cn=Users,secAuthority=Default

dn:cn=Default,secAuthority=Default,cn=JoeSmith,...,c=usobjectclass:secPolicyobjectclass:ePasswordPolicyobjectclass:topcn:Default ***user policy overrides***

Figure 1. User Data


Suffix: secAuthority=default

Cn=Policies,secAuthority=Default

Dn:cn=Default,cn=Policies,secAuthority=Defaultobjectclass:secPolicyobjectclass:ePasswordPolicyobjectclass:topcn:Defaultmaxfailedlogins;10numberwarndays:5passwordmaxage:7862400passwordminage:0passwordmaxrepeatedchars:2passwordminalphachars:4passwordmindiffchars:3passwordminlength:8passwordminotherchars:1passwordreusenum:5passwordtimereuse:0timeexpirelockout:180

Figure 2. Default Policy Data

dn:cn=Default, secAuthority=Default,cn+JoeSmith,...,c=usobjectclass:secPolicy

dn:cn=PolicyData,secAuthority=Default,cn=JoeSmith,...,c=usobjectclass:secPolicyData

Suffix:c=usaclentry:group:CN=ANYBODY:normal:rscaclentry:group:CN=SECURITYGROUPSECAUTHORITY=DEFAULT:object:ad:normal:rwsc:sensitive:rwsc:critical:rwsc

Dn:cn=JoeSmith,...,c=usobjectclass:inetOrgPerson

dn:secAuthority=Default,cn=JoeSmith,...,c=usobjectclass:secUseraclentry:group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULTobject:ad:normal:rwsc:sensitive:rwsc:critical:rwsc

Suffix:secAuthority=Defaultaclentry:grouop:CN=SECURITYGROUPSECAUTHROITY=DEFAULT:object:ad:normal:rwsc:sensitive:rwsc:critical:rwsc

dn:cn=Users,secAuthority=Default

dn:secUUID=f80dc9f8-488c-11d4-98cf-0004ac5e5097cn+Usders,secAuthority=Default

… …

Figure 3. Access Manager’s Use of IBM LDAP ACLs


Chapter 7. Utilities, scripts, and hints for managing IBM LDAPDirectory servers

IBM LDAP Directory’s use of DB2The following Web site contains information on IBM LDAP’s use of DB2:


The key to understanding LDAP’s use of DB2 is the Entry ID, or EID. Every LDAPobject is identified in DB2 by its EID. The following lists various commands forfinding entries and attributes based on EIDs and finding EIDs based on entries andattributes.

To find the full name of a table:db2 list tables | grep -i src

To describe a table:db2 describe table ldapdb2.src

To find the last EID in LDAP:db2 "select * from ldap_next_eid"

To find a user’s EID given a name using DN:db2 "select eid from ldap_entry where dn_trunc = ’OU=EPERSON’"db2 "select ldap_entry.eid,dn_trunc from ldap_entry where dn_trunc =’CN=IVUSER1,OU=EPERSON’"

To find a user’s EID given a name using principalname:db2 "select eid from ldapdb2.principalname where principalname =’IVUSER1’

To find the user’s DN given an EID:db2 "select ldap_entry.dn_trunc from ldap_entry where eid = 100"db2 "select ldap_entry.eid,dn_trunc from ldap_entry where eid = 100"#also displays the eid

The following lists ACL/owner source table search commands:

To display the ACL source table for EID 100:db2 "select * from src where eid = 100"

To display the ACL source table for EIDs between 100 and 110:db2 "select * from src where eid < 110 and eid > 100"

To find the EIDs that do not have a default ACL inheritance (acl owner is -1)from the first 100 entries:

db2 "select * from src where aclsrc = -1 and eid < 100 and eid > 2"

To find EIDs in the ACL source table that are not suffixes and do not have adefault ACL inheritance (from the first 60 entries):

db2 "select eid from src where aclsrc = -1 and eid > 1 and eid < 60 andeid not in (select ldap_entry.eid from ldap_entry where peid = -1)"db2 "select eid from src where aclsrc = -1 and eid > 1 and eid < 60and eid in (select deid from ldap_desc where deid != aeid)"


To find the EIDs in the ACL/owner source table that do not have a default ACLsource and are descendants of suffix with EID 3:

db2 "select src.eid from src,ldap_desc,ldap_entry where aclsrc = -1 andsrc.eid > 1 and src.eid < 60 and deid = src.eid and aeid=3 and peid !=-1 and ldap_entry.eid = src.eid"

To find in the ACL/owner source table for the first ten users who aredescendants of EID 4 (secauthority=default):

db2 "select * from src where src.eid in (select deid fromldapdb2.ldap_desc where (aeid= 4 and deid <10 and deid != 4))"

The following lists ACL/owner source table update commands:

To update the ACL source table for EID 100:db2 "update src set aclsrc = 3 where eid = 100"

To update the ACL source table for all EIDs that are not suffixes and do nothave a default ACL inheritance (from the first 60 entries):

db2 "update src set aclsrc = 3 where eid in (select eid from src whereaclsrc = -1 and eid > 1 and eid < 60 and eid not in (selectldap_entry.eid from ldap_entry where peid = -1))"

To show the ancestors of an EID (from the descendent table):db2 "select * from ldap_desc where deid = 100"

To find the EID for all suffixes:db2 "select ldap_entry.eid from ldap_entry where peid = -1"db2 "select ldap_entry.eid,dn_trunc from ldap_entry where peid = -1"

To assist in finding the EID for the first user bulkloaded (first non-AccessManager-created user):

db2 "select ldap_entry.eid,dn_trunc from ldap_entry,objectclass whereobjectclass.eid < 50 and objectclass.objectclass = ’EPERSON’ andobjectclass.eid = ldap_entry.eid"db2 "select * from objectclass where objectclass = ’EPERSON’ and eid <50"

Distributing the database across multiple physical disksAs the database grows, it becomes necessary and desirable to distribute thedatabase across multiple physical disk drives. Better performance can be achievedby spreading entries across multiple disks. In terms of performance, one 20 GBdisk is not as good as two 10 GB disks. The following sections describe how toconfigure DB2 to distribute the ldapdb2 database across multiple disks.

Background information on LDAP Directory tablespacesWhen the IBM SecureWay LDAP Directory creates a database for the directory, ituses the DB2 create database command to create a database named ldapdb2. IBMSecureWay Directory, Version 3.2.1, creates this database with three SMS (SystemManaged Space) tablespaces. IBM SecureWay Directory, Version 3.2.2, creates thisdatabase with one additional SMS tablespace. with the default database settings.The tablespaces can be viewed using the following DB2 commands executed underthe context of the ldapdb2 users:db2 connect to ldapdb2db2 list tablespaces

Example output for IBM SecureWay Directory, Version 3.2.1 is as follows:


Tablespaces for Current Database

Tablespace ID = 0Name = SYSCATSPACEType = System managed spaceContents = Any dataState = 0x0000

Detailed explanation:Normal

Tablespace ID = 1Name = TEMPSPACE1Type = System managed spaceContents = Temporary dataState = 0x0000


Tablespace ID = 2Name = USERSPACE1Type = System managed spaceContents = Any dataState = 0x0000


For IBM SecureWay Directory, Version 3.2.2, the following additional tablespaceexists:Tablespace ID = 3Name = LDAPSPACE1Type = System managed spaceContents = Any dataState = 0x0000


The LDAP Directory is stored in the user tablespace (USERSPACE1) and, for IBMSecureWay Directory, Version 3.2.2, in the LDAP tablespace (LDAPSPACE). Bydefault, there is only one container or directory for the user tablespace. To view thecontents of the user tablespace, use a DB2 command similar to the following:db2 list tablespace containers for 2

Example output is as follows:Tablespace Containers for Tablespace 2

Container ID = 0Name = /ldapdb2/NODE0000/SQL00001/SQLT0002.0Type = Path

The container or directory that DB2 uses for tablespace 2 is/ldapdb2/SQL00001/SQLT0002.0. For IBM SecureWay Directory, Version 3.2.1, itcontains all the files for the LDAP directory tables. For IBM SecureWay Directory,Version 3.2.2, the directory is also stored in tablespace 3. The biggest table,ldap_entry, contains the majority of the LDAP directory information.

Create file systems and directories on the target disksThe first step in distributing the DB2 database across multiple disk drives is tocreate and format the file systems and directories on the physical disks that thedatabase is to be distributed among. Here are some guidelines:

Chapter 7. Utilities, scripts, and hints for managing IBM LDAP Directory servers 35

v Because DB2 distributes the database equally across all directories, it is a goodidea to make all of the file systems, directories, or both, the same size.

v All directories to be given to DB2 must be completely empty. Remember thatAIX and Solaris operating systems create a lost+found directory at the root ofany created file system. To avoid having to delete the lost+found directory,create subdirectories on the file systems to be given to DB2. For example, createdirectories named 2 for tablespace 2 containers and, for IBM SecureWayDirectory, Version 3.2.2., directories named 3 for tablespace 3 containers on eachdirectory to be given to DB2. For IBM SecureWay Directory, Version 3.2.2, createboth tablespace 2 and 3 directories on each file system to be given to DB2.

v The DB2 instance user must have write permission on the created directories.For AIX and Solaris operating systems, the following command gives the properpermissions:chown ldapdb2 directory_name

The following are operating-system-specific guidelines:v For the AIX operating system, create the file system with the Large File Enabled

option. This is one of the options on the Add a Journaled File System smittymenu.

v For AIX and Solaris operating systems, set the file size limit to unlimited or to asize large enough to allow for the creation of a file as large as the file system.On the AIX operating system, the /etc/security/limits file controls system limitsand –1 means unlimited. On the Solaris operating system, the ulimit commandcontrols system limits.

Backing up the existing databaseTo back up the existing database, follow these steps:1. Stop the LDAP Directory Server process (slapd).2. To close all DB2 connections, enter the following commands:

db2 force applications alldb2 list applications

A message similar to the following is displayed:SQL1611W No data was returned by Database System Monitor.

3. To initiate the back-up process, run the following command:db2 backup db ldapdb2 to [file system | tape device]

When the database has been backed up successfully, a message similar to thefollowing is displayed:Backup successful. The timestamp for this backup image is : 20000420204056

Note: Ensure that the backup process was successful before proceeding. The nextstep destroys the existing database in order to recreate it. If the backup wasnot successful, the existing database is lost. Though not necessary, it is agood idea to verify the success of the backup by restoring to a separatemachine.

Perform a redirected restore of the databaseA DB2 redirected restore restores the specified database tablespace to multiplecontainers or directories. For the purposes of the following example, assume thatthe following directories for containing tablespace 2 have been created, have thecorrect permissions to allow write access by the ldapdb2 instance owner, and areempty.


/disks/1/2/disks/2/2/disks/3/2/disks/4/2/disks/5/2

For the purposes of the following example, assume that IBM SecureWay Directory,Version 3.2.2, is being used and the following directories for tablespace 3 have beencreated:/disks/1/3/disks/2/3/disks/3/3/disks/4/3/disks/5/3

Follow these steps for a redirected restore:1. Start the DB2 restore process, using the following command:

db2 restore db ldapdb2 from [location of backup] replace existing redirect

Messages similar to the following are displayed:SQL2539W Warning! Restoring to an existing database that is the same asthe backup image database. The database files will be deleted.

SQL1277N Restore has detected that one or more tablespace containers areinaccessible, or has set their state to ’storage must be defined’.

DB20000I The RESTORE DATABASE command completed successfully.

2. Define the containers for tablespace 2 and for IBM SecureWay Directory,Version 3.2.2, tablespace 3, using the following command:db2 "set tablespace containers for 2 using (path \’/disks/1/2’, path ’/disks/2/2’, path ’/disks/3/2’, \path ’/disks/4/2’, path ’/disks/5/2’)"

db2 "set tablespace containers for 3 using (path \’/disks/1/3’, path ’/disks/2/3’, path ’/disks/3/3’, \path ’/disks/4/3’, path ’/disks/5/3’)"

Note: These commands can become very long if many containers are defined.They can become so long as to not fit within the limits of a shellcommand. In this case, you can put the command in a file and runwithin the current shell using the dot notation. For example, assume thatthe command are in a file named set_containers.sh. The followingcommand runs it in the current shell:. set_containers.sh

Upon completion of the DB2 set tablespace command, a message similar to thefollowing is displayed:DB20000I The SET TABLESPACE CONTAINERS command completed successfully.

If you receive the following message,SQL0298N Bad container path. SQLSTATE=428B2

it usually indicates that one of the containers is not empty, or that writepermission is not enabled for the ldapdb2 user:

Note: A newly created file system on AIX and Solaris contains a directorynamed lost+found. You should create a directory at the same level aslost+found to hold the tablespace and reissue the set tablespace


command. If you have problems, refer to the DB2 documentation. Thefollowing files also might be of interest:ldapdb2 home dir /sqllib/Readme/en_US/Release.Notesldapdb2 home dir /sqllib/db2dump/db2diag.log

The db2diag.log file contains some fairly low-level details that can bedifficult to interpret.

3. Continue the restore to new tablespace containers. This step takes the mosttime to complete. The time varies depending on the size of the directory. Tocontinue the restore to the new tablespace containers, run the followingcommand:db2 restore db ldapdb2 continue

If anything goes wrong with the redirected restore, and you want to restart therestore process, it might be necessary to first issue the following command:db2 restore db ldapdb2 abort

DB2 backup and restoreThe fastest way to back up and restore the database is to use DB2 backup andrestore commands. LDAP alternatives, such as db2ldif and ldif2db, are generallymuch slower in comparison.

The only disadvantage to using the DB2 backup and restore commands is that thebacked-up database cannot be restored across dissimilar hardware platforms. Forexample, you cannot back up an AIX database and restore it to a Solaris machine.An alternative to the DB2 backup and restore commands is an LDIF export andimport. These commands work across dissimilar hardware platforms, but theprocess is slower. For more information on the use of these commands, refer to theDB2 documentation.

An important advantage of using DB2 backup and restore commands is thepreservation of DB2 configuration parameters and reorgchk database optimizationsin the backed-up database. The restored database has the same tunings as thebacked-up database. This is not the case with LDAP db2ldif and ldif2db.

Be aware that if you restore over an existing database, any tunings on that existingdatabase are lost. Check all DB2 configuration parameters after performing arestore. Also, if you do not know whether a reorgchk was performed before thedatabase was backed up, run reorgchk after the restore. The DB2 commands toperform backup and restore operations are as follows:db2 force applications alldb2 backup db ldapdb2 to <directory_or_device>db2 restore db ldapdb2 from <directory_or_device> replace existing

where directory_or_device is the name of a directory or device where the backup isstored.

The most common error that occurs on a restore is a file permission error.Following are some reasons why this error might occur:v The DB2 instance owner does not have permission to access the specified

directory and file. One way to solve this is to change directory and fileownership to the DB2 instance owner. For example, run the following command:chown ldapdb2 fil_or_dev


v The backed-up database is distributed across multiple directories, and thosedirectories do not exist on the target machine of the restore. Distributing thedatabase across multiple directories is accomplished with a redirected restore. Tosolve this problem, either create the same directories on the target machine orperform a redirected restore to specify the proper directories on the newmachine. If creating the same directories, ensure that the owner of the directoriesis ldapdb2. For more information about redirected restore, see “Distributing thedatabase across multiple physical disks” on page 34.

Backup and restore operations are required to get an LDAP replica initiallysynchronized with an LDAP master, or whenever the master and replica get out ofsync. A replica can get out of sync if it is not defined to the master. In this case, themaster does not know about the replica and does not save updates on apropagation queue for that replica.

If a newly configured master LDAP directory is to be loaded with initial data, youcan use bulk-loading utilities to speed up the process. This is another case inwhich the replica is not informed of updates and a manual backup and restore isrequired to get the replica synchronized with the master.

Monitoring LDAP performanceTo monitor performance for IBM SecureWay Directory and iPlanet Directory, usethe ldapsearch command as follows:ldapsearch -h ldap_host -s base -b cn=monitor "objectclass=*"

where ldap_host is the name of the LDAP host.

This commands returns several statistics. An interesting statistic in terms ofmonitoring performance is opsinitiated, which indicates the number of LDAPoperations that were initiated since the LDAP server started. The ldapsearchcommand itself accounts for three of these operations. Therefore, for any giveninterval, the throughput for that interval is the difference between opsinitiated atthe start and end of that interval, less three for the ldapsearch, divided by thelength of the interval.

Following is a more precise description of this calculation:tput = (opsinitiated(at stop time) - opsinitiated(at start time) - 3) /(stop_time - start_time)

Update performance and SMP systemsIBM SecureWay Directory serializes updates to the LDAP master server. Thismeans that update performance does not benefit from having more than oneprocessor on the LDAP master server. Searching performance benefits frommultiple processors on the LDAP server.

Creating large numbers of usersUsers may be added to Access Manager in a number of ways. The suggestedmethod depends on the number of users that need to be added. The followingtable is useful for determining the preferred method of adding Access Managerusers:


Table 2. Preferred Methods for Adding Users

Number of Users to Create Preferred Method

Less than 10,000 Access Manager pdadmin command

More than 10,000 LDAP bulkload utility with customizableAccess Manager scripts

As reflected in the preceding table, when small numbers of users are to be added,the preferred method is the Access Manager pdadmin command. Detailedinformation on this command can be found in the IBM Tivoli Access Manager BaseAdministrator’s Guide (see “Base information” on page vii. During this process,Access Manager adds users to the LDAP server and in turn, the LDAP server thenadds the user to the DB2 database. The time it takes for this to occur is small butnot insignificant so this method is impractical when more than 10,000 users areadded. Because of the time required to load a large number of users, an alternativeis to bypass Access Manager and the LDAP server and load users directly into theDB2 database using the utility supplied with LDAP.

The bulkload utility is only supported with IBM LDAP. Similar tools exist forother Directory products, such as Active Directory and iPlanet Directory. Some ofthe scripts contained in this section might be useful with the bulk loading of userson these alternative directory products. There is also an command within theLDAP framework that can be used to create users and add them to the DB2database. In the case of groups with large numbers of members, ldapadd ispreferred over the bulkload utility. More information is provided on this later inthe section. For more information about both utilities, refer to the IBM SecureWaydocumentation.

Before attempting any of the procedures which follow, customers are stronglyadvised to back up all critical Access Manager files as well as the user informationin the DB2 database in the event of failure or undesired results. The backup andrestore procedures of a DB2 database are discussed in more detail in “DB2 backupand restore” on page 38.

The LDAP bulkload utilityThe IBM LDAP server comes with an executable called bulkload, which providesthe function of loading information directly into the LDAP from an LDAPInformation File (LDIF). The bulkload utility parses the LDIF, creates files used bythe DB2 loader program, and then proceeds to load the data directly into the DB2database, bypassing LDAP.

There are a number of disadvantages using the bulkload utility as opposed to theAccess Manager pdadmin command. Before using the utility and the associatedscripts, consideration should be given to the following:v The LDAP bulkload utility and custom bulk-loading scripts require LDAP to be

down during their operation.v The LDAP bulkload utility and custom bulk-loading scripts do not handle

LDAP replication.v The LDAP bulkload utility and the associated Access Manager scripts can be

difficult to use.

It is not recommended that the bulkload utility be used to add a large number ofmembers to a group. The resulting group is created in an inefficient manner. Theresult is poor performance when the group is used as part of a directory search orupdate operation. The laid-back utility is recommended for adding a large number


of members to a group. If the bulkload utility is used to create a group with alarge number of members, the authentication of those users defined to that groupbecomes very slow. The utility is recommended for creating large numbers ofmembers of a group.

Replica servers must be synchronized manually after a bulk load execution, suchas after a DB2 backup and restore.

More information on the bulkload utility can be found in the IBM SecureWayDirectory Installation and Configuration Guide(see IBM SecureWay Directory).

Disk space requirementsThe bulkload utility requires a significant amount of temporary disk space. Spaceis required for an LDIF, DB2 import tables, and DB2 indexing. The following tableshows DB2 tablespace requirements assuming 100,000 users are being bulk loaded.

Table 3. Disk Space Requirements

Description Tablespace ID Approximate disk spacerequirements

Temporary LDIF space n/a 705 MB

DB2 data space 2 – (USERSPACE1) 700 MB

DB2 LDAP space 3 – (LDAPSPACE) 400 MB

DB2 data space (version 3.2.1 2 – (USERSPACE) 2000 MB

DB2 uses tablespace 1 for temporary space. One use of temporary space is forindexing which occurs during the bulk-load process. The directory defined forTablespace 1 must be large enough to hold the largest index.

The amount of disk space required can be estimated by the following formulas:temp LDIF space = 7.05 KB * (number of users to be created)DB2 data space = 7 KB * (number of users to be created) #(Version 3.2.2)DB2 LDAP space = 4 KB * (number of users to be created) #(Version 3.2.2)DB2 data space = 20 KB * (number of users to be created using Version 3.2.1)

Note: The preceding estimates on disk space requirements should be consideredminimum requirements. Of the 7.05 KB needed by every user to be created,only about 0.75 KB is actual user data. The remaining space is the amountneeded for manipulation of the data. Therefore, if the users have either alarge number of attributes or attributes populated by large amounts of data,the total amount of disk space needed might be as much as 1.5 to 2 timesgreater than these estimations.

The directory setting for any tablespace can be determined by running thefollowing commands:su - ldapdb2db2 connect to ldapdb2db2 list tablespace containers for ID

The variable ID is the tablespace ID number. The resulting output will reveal thepath to the tablespace directory. The available capacity of the tablespace directorycan then be obtained on an AIX or Solaris system by entering the followingcommand:df -k tablespace_directory


Enter the directory or entire path for the tablespace_directory variable. Moreinformation on tablespaces can be found in “Disk space requirements” on page 41.

Bulk loading and ACLsDo not use the bulkload utility to create LDAP ACLs because it does not performwell when creating ACLs. Instead, use the fixacls.sh script described in “AddAccess Manager ACLs not created by the bulkload utility” on page 15.

Using the Access Manager scriptsCertain directory attributes and objects must exist in order for a user to be usableby Access Manager. The purpose of the bulkload scripts is to take an existing LDIFcontaining the user definitions and include the Access Manager attributes andobjects for each of them. The resulting LDIF is then passed to the LDAP bulkloadutility for loading into the LDAP server.

This section describes the use of three Access Manager bulk-loading scriptsprovided online athttps://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

and in Appendix A, “Scripts” on page 53 of this guide. These scripts should beconsidered examples from which usable scripts are derived. To make the scriptsusable, you must customize them for the particular environment in which they areto be used. The three scripts are:v mk_test_users_ldif.sh

v addpd_to_testusers_ldif.sh

v incremental_bulkload.sh

The scripts are designed to be piped together, so that any piece can easily bereplaced. Note that the scripts have very little error checking and should be readthoroughly before being used. Modifications are required.

The following is a description of each of these scripts.

mk_test_users_ldif.shThis script generates sample directory users without any Access Manager attributesor objects. This script could be replaced with one that gets users from anotherdirectory server or from the same directory server. Users would come from thesame directory. In that case, they are being imported to Access Manager. Userscould come from some other database, such as a database containing employeesand/or customers. The script could be replaced by a cat of file containing the LDIFdefinition of users obtained in one of the previously mentioned ways

This script is to be used as a model of the minimum information needed to definea directory user. It can be used to generate users for testing purposes. This scripthas the following usage:mk_test_users_ldif.sh start_user_number end_user_number

The output from this script is directed to the standard output device and containsthe LDIF definition of the range of users requested on input. The script must bemodified to indicate the LDAP suffix under which the users are to be located inthe directory tree.




addpd_to_testusers_ldif.shThis script adds the Access Manager attributes and objects to the input set of users.The input set of users is read from the standard input device. The original userLDIF definition, along with the added LDIF attributes and objects, is output to thestandard output device. The script can be modified to exclude the original userLDIF definition, in which case it can used to perform an import of existing users toAccess Manager.

Note: This script has a dependency on either the uuidgen or pduuidgen utility,the latter which is shipped with Access Manager. You will need to modifythis script for your particular directory tree structure. Additional variableswithin the script that need to be set are:v sechaspolicy

v secpwdvalid

v secpwdlastchanged

v secacctvalid

More information about the use of pduuidgen can be found in the IBMTivoli Access Manager Base Administrator’s Guide (“Base information” on pagevii).

This script may also need modification for identifying where the Access Managerprincipalname attribute obtained. As written, the script gets the principalnameattribute from the directory user’s uid attribute. An alternative is to get theprincipalname attribute from the cn attribute, assuming all users have a cnattribute.

incremental_bulkload.shThis script invokes the bulkload utility repetitively until all objects are loaded. Thefrequency of invocation is determined by an increment variable within the scriptfile that determines the number directory objects to group together per invocation.The loading of users is faster as the number of directory objects loaded together inone invocation of increases.

Note that the number of Access Manager objects per user, including the LDAP userobject is four. An increment variable of 200000 loads Access Manager users inincrements of a half million.

Be careful about the 2 GB file size limit. File system limits and operating systemlimits may have to be increased to accommodate file larger than 2 GB. Thebulkload utility itself does not support files larger than 2 GB, until after efix 1 forversion 3.2.2. The default increment in the script avoids reaching the 2 GB file sizelimit. The script usage is as follows:incremental_bulkload.sh drop_indexes | with_indexes

The only command line parameter is either drop_indexes or with_indexes. Thedrop_indexes parameter indicates that indexes are to be dropped before doing DB2table loads. The indexes are recreated, either on the next invocation of bulkload orthe next time the slapd process is started.

The with_indexes parameter does not drop indexes before the load. If a relativelysmall number of users are to be loaded, it better to load with indexes left on.Relative is in comparison to the size of existing registry. If the database is emptyand one million users are to be created, it is best to drop the indexes, do the load,then recreate them. In that case, use the drop_indexes option.


The script obtains input from the standard input device. Input is the LDIFdefinition of the objects to be loaded. The script could be replaced with ldapadd orsome other utility that provides fast loading capabilities on some other directoryproduct.

The script writes to the standard output device for progress messages and timings.

The Access Manager bulkload scripts should be run on the machine on which theLDAP and DB2 servers are installed. The scripts are ksh scripts and should be runinside a ksh shell.

The example scripts could be used in the following way to load 10,000 test users:mk_test_users_ldif.sh 1 10000 | addpd_to_groups_ldif.sh | \incremental_bulkload.sh with_indexes

When running this script, do not be alarmed if it appears to hang. The parsingphase of the bulkload utility is a lengthy process and grows linearly with the sizeof the LDIF.

To view the scripts, see Appendix A, “Scripts” on page 53. The files can bedownloaded from:https://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

After completing the bulk-loading process, run the following:v Perform the tunings described in “Tuning after a large number of updates” on

page 16.v If there are any replicas, manually synchronize them with the updated database.

LDAP replicas are not aware of the changes made by the bulkload utility. TheDB2 backup and restore procedure on page 38 is a good way to perform themanual synchronization.

Adding a large number of members to a groupTo add a large number of members to a group, use the ldapadd utility withincrements of 10,000 users at a time. The reason for breaking them up intoincrements is the potential for running out of disk space for the DB2 transactionlog, which is another part of the DB2 database that is stored in tablespace 1. TheDB2 transaction log is used to back out any changes to an entry in the event that afailure occurs before the changes are complete and committed to the database. Thetransaction log contains a record of the progress of the ldapadd.

If more than 10,000 members are added at a time, this log can become very large.If the file system for tablespace 1 runs out of space, the ldapmodify fails. Youshould perform a DB2 backup before adding a large group. Running out of diskspace can put the database in an unrecoverable state.

This section describes the use of three Access Manager scripts to aid in the addingof a large number of members to a group. These scripts are provided online athttps://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

in Appendix A, “Scripts” on page 53 of this guide. These scripts should beconsidered examples from which usable scripts are derived. To make the scriptsusable, you must customize them for the particular environment in which they willbe used. The three scripts are:






mk_test_group_ldif.shaddpd_to_groups_ldif.shincremental_group.sh

The scripts are designed to be piped together, so that any piece can easily bereplaced. Note that these scripts have very little error-checking and should be readthoroughly be for being used. Modifications are required. The following is adescription of each of these scripts.

mk_test_group_ldif.shThis script creates a test group with the number of test users specified on input oradds the number of test users specified on input to an existing group. The groupdoes not contain the Access Manager attributes and objects. It is a group as definedby the directory server.

The suffix under which the group and users are located in the directory tree issomething to customize within the script file. The groups and group membershipcould come from some other source. This script could be replaced with a cat of afile containing the LDIF definition of the directory group object.

The script could be used to create a test group with many members. The usage isas follows:mk_test_group_ldif.sh create | add start_user_number end_user_number

where the first parameter is either create or add. The create option generates theLDIF to create a directory group object without the Access Manager attributes andobjects. The group is created with the specified number of members. The addoption adds the specified members to an already existing group.

The start_user_number and end_user_number variables define the range of test usersto be added to the test group. The name of the group, the suffix, and the userprefix are variables that can be changed from within the script file.

The script directs the LDIF output of the group definition to the standard outputdevice.

addpd_to_groups_ldif.shThis script adds the Access Manager attributes and objects to the input group orset of groups. The input group or groups is read from the standard input device.The original group LDIF definition along with the added LDIF attributes andobjects is output to the standard output device. The script could be modified toexclude the original group LDIF definition, in which case it could used to performan import of existing groups to Access Manager. The script accepts any LDIF datafrom the input stream, but only acts upon the LDIF that creates group objects. Allother LDIF data is simply passed on through to the standard output deviceunchanged. For example, LDIF data that adds members to an existing group orcreates non-group objects is echoed to the standard output device without change.

This may also need modification for identifying where the Access Manager’s cnattribute is obtained. The cn attribute is the Access Manager’s definition of thegroup name. As written, the script assumes directory groups are named by the cnattribute.

incremental_groups.shThis script divides the input LDIF group membership definition into theincrements that are loaded separately into the SecureWay Directory using theldapadd utility. The size of each increment is defined in the script and defaults to


10,000. Each incremental set of members is loaded in a separate invocation ofldapadd. All non-group objects are passed, unchanged, to the ldapadd utility.

Adding groups and the DB2 LOGFILSIZ parameterFor a slight improvement in the performance of this utility, the increment variablecan be increased. This results in a larger number of members being loaded on eachincremental load and fewer total number of loads. If the increment variable isincreased, an adjustment to the DB2 LOGFILSIZ parameter is necessary. Otherwise,the ldapadd utility fails and the cli.error file contains a message similar to thefollowing:03/08/02 12:16:43 PM native retcode = -964; state = "57011";message = "[IBM][CLI Driver][DB2/SUN] SQL0964C The transactionlog for the database is full. SQLSTATE=57011’

Refer to “Do DB2 parameter tuning” on page 5 for more information on settingDB2 parameters. The command for setting the DB2 LOGFILSIZ is as follows:db2 update db config for ldapdb2 using LOGFILSIZ 10000

The default size is 1000. A size of 10000 will allow for an increment of 100,000members per invocation to ldapadd.

Using the group scripts togetherThe example scripts could be combined in the following way to load a groupcontaining 10,000 users:mk_test_group_ldif.sh create 1 10000 | addpd_to_groups_ldif.sh | \incremental_group.sh

The example scripts could be combined in the following way to add 10000additional members to the group created in the first example:mk_test_group_ldif.sh add 10001 20000 | addpd_to_groups_ldif.sh | \incremental_group.sh

The invocation of addpd_to_groups_ldif.sh is optional in the previous example,and could also have been shown as follows:mk_test_group_ldif.sh add 10001 20000 | incremental_group.sh


Chapter 8. Process memory size limits

On UNIX platforms, some of LDAP and Access Manager tunings in this documentresult in process sizes that exceed the operating system default limits. This sectiondescribes how to increase the operating system limits so that the affected processesdo not run out of memory and crash.

When a process runs out of memory, it often ends. In some cases, it leaves a coredump file, an error message, or an error log entry. On AIX systems, the systemerror log may indicate that the process ended due to memory allocation failure.Use the errrpt –a | more command to display the error log.

Increasing the operating system process memory size limitsOn AIX, the process size limits are defined in the file. A value of -1 indicates thatthere is either no limit or it is unlimited. The names of the limits to increase areand rss.

On Solaris, the process size limits are defined by the ulimit command. A value ofunlimited can be specified on the command. The names of the limits to increaseare data and vmemory.

The most useful setting to use for the process size limits is unlimited. That way,the system process size limits are defined so as to allow the maximum processgrowth.

For more information about increasing memory size limits, see [UNIX oper systuning 3]

AIX-specific process size limitsOn AIX, the number of data segments that a process is allowed to use also limitsthe process memory size. The default number of data segments is one. The size ofa data segment is 256 MB. Data segments are shared for both data and stack. Themaximum number of additional data segments a process can use is eight.

Setting the maximum number of AIX data segments that aprocess can use (LDR_CNTRL)

In AIX, Version 4.3.3, the number of segments that a process can use for data iscontrolled by the LDR_CNTRL environment variable. It is defined in the parentprocess of the process that is to be affected. For example, the following defines oneadditional data segment:export LDR_CNTRL =MAXDATA=0x10000000start_processunset LDR_CNTRL

It is a good idea to unset the LDR_CNTRL environment variable, so that it does notunintentionally affect other processes.

Unlike other environment variables for the IBM SecureWay Directory serverprocess (slapd), the LDR_CNTRLenvironment variable cannot be set as a front-endvariable in the slapd32.conf file. It must be set as an environment variable.


The following table shows the LDR_CNTRL setting and memory increase for variousnumbers of data segments:

Table 4. LDR_CNTRL Settings

LDP_CNTRL Setting Number ofAdditionalSegments

Process MemoryLimit Increase

Unset 0 (default) 256 MB

LDR_CNTRL=MAXDATA=0x1000000 1 512 MB

LDR_CNTRL=MAXDATA=0x2000000 2 768 MB

LDR_CNTRL=MAXDATA=0x3000000 3 1 GB

LDR_CNTRL=MAXDATA=0x4000000 4 1.25 GB



LDR_CNTRL=MAXDATA=0x7000000 7 2 GB


If an invalid setting is used for LDR_CNTRL, it is ignored and the default onesegment usage is defined.

AIX data segments and LDAP process DB2 connectionsSegments have another use AIX. They can be used for shared memorycommunication between processes. The LDAP server process, slapd, makes use ofshared memory segments for connections to DB2. The number of segments that theLDAP process uses for DB2 connections is defined by the ibm-slapdDbConnectionsparameter in the /etc/slapd32.conf file.

The total number of segments used by a process cannot exceed eight. This is thesum of the additional data segments and the shared memory segments. If the sumis greater than eight, the difference is made up in reduced DB2 connections. Nomessage is given nor does the LDAP server fail when the sum of the segment usesexceeds 8. This is typically not a concern, since cache sizes large enough to make asignificant reduction in DB2 connections are not practical. See “Using LDAP cache”on page 21 for more information.

Verifying process data segment usageIf the perfagent.tools are installed, the /usr/bin/svmon -P pid command showsthe memory usage of a process. In the output, identify the segments labeledshmat/mmap. Segments with an Inuse column of zero (0) are for data segments thatare available for process growth. Segments with an Inuse column greater than 1are for data segments in which the process has already grown. Segments with anInuse column of 1 are usually found in the slapd process and represent the sharedmemory segments being used for DB2 connections.


Chapter 9. Troubleshooting

When a problem occurs that appears to be related to the SecureWay Directoryserver, the following files should be checked for error messages first:v slapd.errors

v cli.error

The location of the slapd.errors file is /var/ldap/slapd.errors on Solaris and/tmp/slapd.errors on AIX. The location of the slapd.errors file is also recorded inthe slapd32.conf file. The location of the cli.error file is in the same directory asthe slapd.errors.v Problem: Get message SQL1478W The database has been started but only one

buffer pool has been activated. SQLSTATE=01626 on db2 connect toldapdb2or a similar message when starting slapd.Cause 1: On Solaris, this is typically due to the shmsys:shminfo_shmmaxparameter in /etc/system not being set high enough to support the DB2 cache.Solution: Change the value of the shmsys:shminfo_shmmax in the /etc/system fileand reboot the system. Refer to “Increase the shared memory maximum(shmmax)” on page 3 for more information.Cause 2: This problem can also occur when the UTIL_HEAP_SZ DB2 configurationparameter is set too high.Solution: Switch to the ldapdb2 users (su – ldapdb2) and reduce theUTIL_HEAP_SZ configuration parameter. For example, run the followingcommand:db2 update db config for ldapdb2 using UTIL_HEAP_SZ 5000

Cause 3: This problem can occur when the DB2 buffer pool sizes are set toohigh.

Solution: Switch to the ldapdb2 users (su – ldapdb2) and reduce the buffer poolconfiguration parameter. See “Do DB2 parameter tuning” on page 5 for moreinformation.

v Problem: The /export/home/ldapdb2/sqllib/db2dump/db2diag.log file reports amessage similar to the following:

SQL8017W The number of processors on this machine exceeds the defined entitlementof "1" for the product "DB2 Enterprise Edition". The number of processors on thismachine is "4".

Solution: Purchase an updates license and then use db2licm to update themachine license. For example, issue db2licm –l to get the password, then issuedb2licm –n DB2UDBEE 4 to do the update. In this example, the password isDB2UDBEE and the number of processors is 4.

v Problem: LDAP/DB2 fails to start and there is no message in the LDAP errorlog. It returns to the command prompt when attempting to start slapd.Cause: The DB2 BUFFPAGE parameter is set too high for the available physicalmemory and paging space.Solution: Decrease the buffer pool size. See “Do DB2 parameter tuning” onpage 5“Do DB2 parameter tuning” on page 5.

v Problem: The SQL1220N The database manager shared memory set cannot beallocated. message is displayed.


Cause: An insufficient size for the shared memory maximum has been set.Solution: Refer to “Increase the shared memory maximum (shmmax)” on page3.

v Problem: After a DB2 restore, LDAP and DB2 fail to start with a messageindicating that the database needs to be migrated.Cause: See “Do DB2 parameter tuning” on page 5 for reasons why this occurs.Solution: The workaround is to create a script that continuously loops and setsthe DB2 BUFFPAGE parameter every five seconds. Run the script during therestore process. Ensure that the bufferpool is defined with a size of –1 beforerunning the script. For example:db2 connect to ldapdb2while [ 1 = 1 ];do

sleep 5db2 update database configuration for ldapdb2 using BUFFPAGE 16000

done

v Problem: ldapsearch commands return with an operations errors. AccessManager returns errors indicating that the registry is not available. Theldapsearch command returns with no results, when results are expected.Cause: DB2 has been forcefully stopped, using db2 terminate, and possiblydb2stop and db2start.Solution: Restart LDAP.

v Problem: ldapsearch commands do not fail, but return no results when resultsare expected.Cause: Authentication parameters on ldapsearch were either not specified orincorrectly specified. For example, the –D and –w parameters were not specified.Solution: Reissue the command with the authentication parameters specified, forexample, –D and –w.

v Problem: DB2 runstat fails with the following message:SQL2310N The utility could not generate statistics.Error "-1024" was returned

Cause: A DB2 connection does not exist.

Solution: Run the db2 connect to ldapdb2 command and try again.v Problem: An Access Manager server ends unexpectedly, but leaves no message

or error log entry.Cause: The process ran out of memory, due to lack of paging space or systemprocess limits.Solution: Either increase the machine’s physical memory, the operating system’spaging space, or the system process limits and try again. Refer to Chapter 8,“Process memory size limits” on page 47 for information about increasing thesystem processlimits..

v Problem: DB2 backup fails with the messageSQL2009C There is not enough memory available to run the utility.

Cause: The DB2 UTIL_HEAP_SZ is not set high enough for the backup utility.

Solution: Increase the DB2 UTIL_HEAP_SZ configuration parameters using the db2update database configuration for ldapdb2 using UTIL_HEAP_SZ command.

v Problem: There is an LDAP or DB2 error message indicating that the transactionlog for the database is full.Cause: The LOGFILSIZ_DB2 parameter is set too low.


Solution: Create the LOGFILSIZ_DB2 parameter using the command:db2 update database configuration for ldapdb2 using LOGFILSIZ 10000

Ensure that there is enough file space in the ldapdb2 user home directory.

Chapter 9. Troubleshooting 51

Appendix A. Scripts

This appendix contains sample scripts for your review.

The scripts are also available online at:https://www.tivoli.com/secure/support/downloads/secureway/policy_dir/downloads.html

The following scripts are provided in this appendix:v do_tunings_322.sh and do_tunings_321.sh starting on page 53.v check_indexes.sh starting on page 54.v check_ldap_acls.sh starting on page 57.v fixacls.sh, fixacls2.sh, and fixacls3.sh starting on page 59.v syssat_tune.sh starting on page 66.v test_registry_perf.sh starting on page 67.v mk_test_users.sh starting on page 68.v addpd_to_testusers.sh starting on page 69.v incremental_bulkload.sh starting on page 71.v mk_test_group_ldif.sh starting on page 75.v addpd_to_groups.sh starting on page 76.

do_tunings_322.sh and do_tunings_321.shThe file system owner of this script should be the ldapdb2 user and the file systemgroup should be dbsysadm. The script must be run under the context of thelaapdb2 user. Here is the source of the do_tunings_322.sh script:

# Restrictions:# This script must be run under the context of the ldapdb2 user. It does not# require write authority to the current directory.

db2 get database configuration for ldapdb2 | \egrep ’BUFFPAGE|DBHEAP|SORTHEAP|MAXLOCKS|MINCOMMIT| \UTIL_HEAP_SZ|LOGFILSIZ’

#db2 update database configuration for ldapdb2 using BUFFPAGE 256000#db2 update database configuration for ldapdb2 using DBHEAP 10000db2 update database configuration for ldapdb2 using SORTHEAP 2500db2 update database configuration for ldapdb2 using MAXLOCKS 100db2 update database configuration for ldapdb2 using MINCOMMIT 25db2 update database configuration for ldapdb2 using UTIL_HEAP_SZ 5000db2 update database configuration for ldapdb2 using LOGFILSIZ 10000

db2 connect to ldapdb2

# the 3.2.2 defaults#db2 alter bufferpool ibmdefaultbp size 29500#db2 alter bufferpool ldapbp size 1230# from LDAP tuning guide example:#db2 alter bufferpool ibmdefaultbp size 100000#db2 alter bufferpool ldapbp size 25000# from LDAP tuning guide for machines with less than 256 MB of RAMdb2 alter bufferpool ibmdefaultbp size 49800db2 alter bufferpool ldapbp size 400




# from LDAP tuning guide 3 to 1 ratio#db2 alter bufferpool ibmdefaultbp size 235930#db2 alter bufferpool ldapbp size 9830

db2 terminatedb2 force applications allsleep 1db2stopdb2start

db2 connect to ldapdb2db2 "select bpname,npages,pagesize from syscat.bufferpools"db2 terminate

Here is the source of the do_tunings_321.sh script:


db2 get database configuration for ldapdb2 | \egrep ’BUFFPAGE|DBHEAP|SORTHEAP|MAXLOCKS|MINCOMMIT|UTIL_HEAP_SZ|LOGFILSIZ’

db2 update database configuration for ldapdb2 using BUFFPAGE 16000#db2 update database configuration for ldapdb2 using DBHEAP 1800db2 update database configuration for ldapdb2 using SORTHEAP 2500db2 update database configuration for ldapdb2 using MAXLOCKS 100db2 update database configuration for ldapdb2 using MINCOMMIT 25db2 update database configuration for ldapdb2 using UTIL_HEAP_SZ 5000db2 update database configuration for ldapdb2 using LOGFILSIZ 10000


db2 "alter bufferpool ibmdefaultbp size -1"

db2 terminatedb2 force application allsleep 1db2stopdb2start

db2 connect to ldapdb2db2 select "* from syscat.bufferpools"db2 terminate

check_indexes.shThe file system owner of this script should be the ldapdb2 user and the file systemgroup should be dbsysadm. The script must be run under the context of theldapdb2 user.

Note that the script shows an example of the usage of the DB2 cursor functional.The usage of DB2 cursors is one of the ways of pacing output from a DB2 selectcommand.

Here is the source of the check_indexes.sh script:#!/bin/ksh

# script to determine whether all tables that exist have an index on eid and any# other index important to PD


# Restrictions:# This script must be run under the context of the ldapdb2 user. It# requires write authority to the current directory for temporary# files.

if [ `uname` = "SunOS" ];thenAWK=nawkelseAWK=awkfi

db2 connect to ldapdb2 >/dev/null

cat << EOF | sort >noneid_idxs_needed.tmpALIASEDOBJECT:ALIASEDOBJECT:+ALIASEDOBJECT_T+EID:DALIASEDOBJECT:RALIASEDOBJECT:+RALIASEDOBJECT_T+EID:DCN:CN:+CN_T+EID:DCN:RCN:+RCN_T+EID:DDESCRIPTION:DESCRIPTION:+DESCRIPTION_T+EID:DDESCRIPTION:RDESCRIPTION:+RDESCRIPTION_T+EID:DLDAP_DESC:LDAP_DESC_AEID:+DEID+AEID:D#LDAP_DESC:LDAP_DESC_DEID:+AEID+DEID:DLDAP_ENTRY:LDAP_ENTRY_PEID2:+PEID:DLDAP_ENTRY:LDAP_ENTRY_PEID:+EID+PEID:DLDAP_ENTRY:LDAP_ENTRY_TRUNC:+DN_TRUNC:DMAIL:MAIL:+MAIL_T+EID:DMAIL:RMAIL:+RMAIL_T+EID:DMEMBER:MEMBER:+MEMBER_T+EID:UMEMBER:RMEMBER:+RMEMBER_T+EID:DOBJECTCLASS:OBJECTCLASS:+OBJECTCLASS+EID:DOBJECTCLASS:ROBJECTCLASS:+ROBJECTCLASS+EID:DPRINCIPALNAME:PRINCIPALNAME:+PRINCIPALNAME_T+EID:DPRINCIPALNAME:RPRINCIPALNAME:+RPRINCIPALNAME_T+EID:DSECAUTHORITY:RSECAUTHORITY:+RSECAUTHORITY+EID:DSECAUTHORITY:SECAUTHORITY:+SECAUTHORITY+EID:DSECDN:RSECDN:+RSECDN+EID:DSECDN:SECDN:+SECDN+EID:DSECUUID:RSECUUID:+RSECUUID+EID:DSECUUID:SECUUID:+SECUUID+EID:DSN:RSN:+RSN+EID:DSN:SN:+SN+EID:DSYS:RSYS:+RSYS_T+EID:DSYS:SYS:+SYS_T+EID:DTARGETSERVICE:RTARGETSERVICE:+RTARGETSERVICE_T+EID:DTARGETSERVICE:TARGETSERVICE:+TARGETSERVICE_T+EID:DTELEPHONENUMBER:RTELEPHONENUMBER:+RTELEPHONENUMBER+EID:DTELEPHONENUMBER:TELEPHONENUMBER:+TELEPHONENUMBER+EID:DTSNAME:RTSNAME:+RTSNAME+EID:DTSNAME:TSNAME:+TSNAME+EID:DTSTYPE:RTSTYPE:+RTSTYPE+EID:DTSTYPE:TSTYPE:+TSTYPE+EID:DUID:RUID:+RUID_T+EID:DUID:UID:+UID_T+EID:DUNIQUEMEMBER:RUNIQUEMEMBER:+RUNIQUEMEMBER_T+EID:DUNIQUEMEMBER:UNIQUEMEMBER:+UNIQUEMEMBER_T+EID:UACLPERM:ACLDN_T_INDEX:+ACLDN_TRUNC:DENTRYOWNER:OWNERDN_T_INDEX:+OWNERDN_TRUNC:DPOSTALADDRESS:POSTALADDRESS:+POSTALADDRESS_T+EID:DPOSTALADDRESS:RPOSTALADDRESS:+RPOSTALADDRESS_T+EID:DEOF

print "Finding all defined indexes"

db2 "list tables" | $AWK ’{if ($2 == "LDAPDB2"){print $1}}’ | sort >all_tables.tmp

rm -f eid_idxs.tmprm -f noneid_idxs.tmp

Appendix A. Scripts 55

for i in `cat all_tables.tmp`;do

db2 describe indexes for table ldapdb2.$i show detail | grep LDAPDB2 | \$AWK -v tbl=$i ’{if ($5 == "+EID" && $3 == "D"){fn = "eid_idxs.tmp"} else {fn = "noneid_idxs.tmp"}print tbl":"$2":"$5":"$3 >> fn#print tbl >> "all_tables.tmp"}’done

# Determine whether there are any missing eid indexes

print "Checking for missing EID indexes"

sort eid_idxs.tmp >eid_idxs_sorted.tmpmv eid_idxs_sorted.tmp eid_idxs.tmp

# create the set of tables that have an eid indexcat eid_idxs.tmp | $AWK -F ":" ’{print $1}’ | sort -u >eid_idx_tables.tmp

diff all_tables.tmp eid_idx_tables.tmp | grep "<" | $AWK ’{if ($2 != "CHANGE" &&$2 != "LDAP_DESC" &&$2 != "LDAP_ENTRY" &&$2 != "LDAP_NEXT_EID" &&$2 != "PROGRESS" &&$2 != "REGISTER" &&$2 != "EXPLAIN_ARGUMENT" &&$2 != "EXPLAIN_OBJECT" &&$2 != "EXPLAIN_OPERATOR" &&$2 != "EXPLAIN_PREDICATE" &&$2 != "EXPLAIN_STATEMENT" &&$2 != "EXPLAIN_STREAM" &&$2 != "EXPLAIN_INSTANCE"){print $2}}’ >potential_missing.tmp

found=0for i in `cat potential_missing.tmp`;do

db2 "declare c cursor with hold for select * from $i" >/dev/nulldb2 "open c" >/dev/nulldb2 fetch c for 10 row | grep selected | \$AWK ’{if ($1 == 10){print 1}else{print 0}}’ >hasrow.tmphasrow=`cat hasrow.tmp`rm -f hasrow.tmpdb2 "close c" >/dev/null

if [ $hasrow = 1 ];thenfound=1print "Missing index: $i"print " Recommend recovery: db2 create index $i""I on $i(eid)"fidone

if [ $found = 0 ];thenprint " No missing EID indexes found"fi

rm -f potential_missing.tmprm -f eid_idxs.tmp


rm -f eid_idx_tables.tmp

# Determine whether there are any missing non-eid indexesprint "Checking for missing non-EID indexes"

sort noneid_idxs.tmp >noneid_idxs_sorted.tmpmv noneid_idxs_sorted.tmp noneid_idxs.tmp

# create lists with index names removed for comparison purposescat noneid_idxs_needed.tmp | $AWK -F ":" ’{print $1":"$3":"$4}’ | sort >nei_needed_short.tmpcat noneid_idxs.tmp | $AWK -F ":" ’{print $1":"$3":"$4}’ | sort >nei_short.tmp

diff nei_needed_short.tmp nei_short.tmp | grep "<" | \$AWK ’{print $2}’ >potential_missing.tmp

found=0for i in `cat potential_missing.tmp`;do

tbl=ècho $i | $AWK -F ":" ’{print $1}’`

# Determine whether the table is even defined in this databasetbl_defined=`grep $tbl all_tables.tmpìf [ "X$tbl_defined" != "X" ];then

# Determine whether the table as any data

db2 "declare c cursor with hold for select * from $tbl" >/dev/nulldb2 "open c" >/dev/nulldb2 fetch c for 1 row | grep selected | $AWK ’{print $1}’ >hasrow.tmphasrow=`cat hasrow.tmp`rm -f hasrow.tmpdb2 "close c" >/dev/null

if [ $hasrow = 1 ];then

indx_def_coded=ècho $i | $AWK -F ":" ’{print $2}’`

indx_name=`cat noneid_idxs_needed.tmp | \$AWK -F ":" -v idx_def=$indx_def_coded \-v tbl=$tbl ’{if ($1 == tbl && $3 == idx_def){print $2exit}}’`

indx_def=ècho $indx_def_coded | $AWK -F "+" ’{for (i=2;ifor (i=2;i

check_ldap_acls.shThis script can be run under the context of any user. The file system owner andgroup must enable the user permission to execute the file.

Here is the source of the check_ldap_acl.sh script:#!/bin/ksh

# script to check and produce ldif for fixing up ACLs on LDAP suffixes. The# goal is to get the LDAP ACLs to the values preferred by Policy Director.

# Restrictions:# This script can be run under the context of any user. It# requires write authority to the current directory for temporary# files.



usage(){

print "Usage: $0 <ldap host> <ldap password>"exit -1

}

if [ "X$1" = "X" ] || [ "X$2" = "X" ];thenusage

fi

ldaphost=$1ldappwd=$2

# a function to compare the results of the suffix searches on acl attributes# and generate ldif to add anything that is missing

search_compare_fix(){

# inputsrchbase=$1prev_result=$2 # a file name

ldapsearch -h $ldaphost -D cn=root -w $ldappwd -s base -b $srchbase"objectclass=*" \ ownerpropagate entryowner aclpropagate aclentry |sort >cur_result.tmp

if [ "X`cat cur_result.tmp`" = "X" ];thenrm -f cur_result.tmpreturnfi

diff $prev_result cur_result.tmp | grep "<" | $AWK -v dn=$srchbase ’{

attr = substr($2,1,index($2,"=")-1)val = substr($2,index($2,"=")+1)

print ""print "dn: "dnprint "changetype: modify"

if (attr == "aclentry"){print "add: "attr}else{print "replace: "attr}print attr": "val}’

rm -f cur_result.tmp}

# First, check "secauthority=default" suffixe

cat << EOF >sec_req_acls.tmpaclentry=group:CN=IVACLD-SERVERS,CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:normal:rscaclentry=group:CN=REMOTE-ACL-USERS,CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT


:normal:rscaclentry=group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULT:object:ad:normal:rwsc:sensitive:rwsc:critical:rwscaclpropagate=TRUEentryowner=group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULTownerpropagate=TRUEEOF

search_compare_fix secauthority=default sec_req_acls.tmp

# Now, check non-"secauthority=default" suffixes

#aclentry=group:CN=ANYBODY:normal:rsc

cat << EOF >nonsec_req_acls.tmpaclentry=group:CN=IVACLD-SERVERS,CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:normal:rscaclentry=group:CN=REMOTE-ACL-USERS,CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:normal:rscaclentry=group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULT:object:ad:normal:rwsc:sensitive:rwsc:critical:rwscaclpropagate=TRUEentryowner=access-id:CN=ROOTownerpropagate=TRUEEOF

ldapsearch -L -h $ldaphost -D cn=root -w $ldappwd -s base -b "" "objectclass=*"namingcontexts | \ grep "namingcontexts:" | grep -iv "CN=SCHEMA" |grep -iv "SECAUTHORITY=DEFAULT" | \ grep -iv "CN=LOCALHOST" |$AWK ’{print $2}’ >suffixes.tmp

for i in `cat suffixes.tmp`;do

search_compare_fix $i nonsec_req_acls.tmp

done

rm -f suffixes.tmprm -f nonsec_req_acls.tmprm -f sec_req_acls.tmp

fixacls.sh, fixacls2.sh, and fixacls3.shThe file system owner of these scripts should be the ldapdb2 user and the filesystem group should be dbsysadm. The scripts must be run under the context ofthe ldapdb2 user.

Note that these scripts make use of EID ranges to pace the output from the DB2select command. The number of entries processed in a single update must belimited, so that the DB2 transaction log does not grow to exceed available diskspace. The DB2 transaction log is used to back out partial updates in the event thatthe command fails in the middle of making an update. DB2 treats updatecommands as atomic operations. An update command either succeeds or fails, butis never partial.

Here is the source of the fixacls.sh script:#!/bin/ksh

# Script to fix up the acls for policy director objects with secmap, secuser, and# secpolicydata objectclasses and LDAP user objects with inetorgperson objectclass.## The script first determines the EIDs to use for inheritance. Some help from the# user is prompted in the form of choosing a suffix. Next, a general cleanup of


# null entries in the aclperm table is done. The final steps involve looping# through all eids in the system and doing the following.# 1) Set the source table for objects with specific objectclasses to inherit from# the identified suffixes.


# The following defines the maximum number of updates that will be done at one time.# The larger this variable is the more disk space is used by the transaction log.grouping=50000


date


# obtain eid of secauthority=default for PD object acl inheritancedb2 "select ldap_entry.eid from ldap_entry where dn_trunc = ’SECAUTHORITY=DEFAULT’"| \ $AWK ’{if (index($0,"-")){getline;print $1}}’ >eid.tmppdobj_acl_inherit=`cat eid.tmp`

# obtain eid for LDAP user acl inheritanceprint Enter the DN of a suffix from which LDAP users inherit their ACLs.print Below are some possible choices:

# get the eids for all suffixesdb2 select eid from ldap_entry where peid = -1 | \$AWK ’{if (index($0,"-")){getline;while ($1 != ""){print $1;getline}}}’ >eid.tmpsuf_eids=`cat eid.tmp`

# get the dns from the eidsrm -f suf_dns.tmpfor i in $suf_eids;do

db2 select ldap_entry.dn_trunc from ldap_entry where eid = $i | \$AWK ’{if (index($0,"-")){getline;print $1}}’ >>suf_dns.tmp

done

# filter out the pseudo suffixes and printcat suf_dns.tmp | grep -iv "cn=localhost" | grep -iv "secauthority=default"

read dn?"Enter DN (must be all capitals letters) or Ctrl-c to exit: "

# obtain eid of the entered DNdb2 "select ldap_entry.eid from ldap_entry where dn_trunc = ’$dn’" | \$AWK ’{if (index($0,"-")){getline;print $1}}’ >eid.tmpldapuser_acl_inherit=`cat eid.tmp`

rm -f eid.tmprm -f suf_dns.tmp

#print $ldapuser_acl_inherit

if [ "X$ldapuser_acl_inherit" = "X" ];thenprint "Error: Invalid DN or DN does not exist"exit -1fi


# Do some general cleanup of unused entries in the LDAP ACL table

# delete entries from the aclperm table that have null acldn’sprint Deleting entries from the aclperm table that have null acldn\’sdb2 "delete from aclperm where acldn like ’’ "

# get the maximum eid

#LDAP 3.2.1 way: db2 "select * from ldap_next_eid" | \db2 "select max(eid) from ldap_entry" | \$AWK ’{if (index($0,"-")){getline;print $1}}’ >eid.tmpmax_eids=`cat eid.tmp | $AWK ’{print $1}’`rm -f eid.tmp

#print $max_eids

# loop doing the acl fixups

i=0while [ $i -le $max_eids ]; do

j=$(( $i+$grouping+1 ))

print updating entries $i through $j : timestamp = $SECONDS seconds

cmd="db2 update src set aclsrc = $pdobj_acl_inherit where aclsrc = -1 \and eid in (select eid from objectclass \where eid > $i and eid < $j and (objectclass = ’SECMAP’ or \objectclass = ’SECUSER’ or objectclass = ’SECPOLICYDATA’))"

print $cmd$cmd

cmd="db2 update src set aclsrc = $ldapuser_acl_inherit where aclsrc = -1 \and eid in (select eid from objectclass \where eid > $i and eid < $j and objectclass = ’INETORGPERSON’)"

print $cmd$cmd

i=$(( $j - 1 ))done

date

Here is the source of the fixacls2.sh script:#!/bin/ksh

# Script to fix up the acls for policy director objects with secmap, secuser, and# secpolicydata objectclasses and LDAP user objects with inetorgperson objectclass.## The script first determines the EIDs to use for inheritance. Some help from the# user is prompted in the form of choosing a suffix. Next, a general cleanup of# null entries in the aclperm table is done. The final steps involve looping# through all eids in the system and doing the following.# 1) Set the source table for objects with specific objectclasses to inherit from# the identified suffixes.# 2) Delete entries in the aclperm table that step one makes no longer necessary.


# The following defines the maximum number of updates that will be done at one time.# This is important in order to keep the size of the change log small.grouping=50000



date



# obtain eid for LDAP user acl inheritanceprint Enter the DN of a suffix from which LDAP users inherit their ACLs.print Below are some possible choices:

# get the eids for all suffixesdb2 select eid from ldap_entry where peid = -1 | \$AWK ’{if (index($0,"-")){getline;while ($1 != ""){print $1;getline}}}’>eid.tmpsuf_eids=`cat eid.tmp`

# get the dns from the eidsrm -f suf_dns.tmpfor i in $suf_eids;do

db2 select ldap_entry.dn_trunc from ldap_entry where eid = $i | \$AWK ’{if (index($0,"-")){getline;print $1}}’ >>suf_dns.tmp

done

# filter out the pseudo suffixes and printcat suf_dns.tmp | grep -iv "cn=localhost" | grep -iv "secauthority=default"

read dn?"Enter DN (must be all capitals letters) or Ctrl-c to exit: "

# obtain eid of the entered DNdb2 "select ldap_entry.eid from ldap_entry where dn_trunc = ’$dn’" | \$AWK ’{if (index($0,"-")){getline;print $1}}’ >eid.tmpldapuser_acl_inherit=`cat eid.tmp`


#print $ldapuser_acl_inherit

if [ "X$ldapuser_acl_inherit" = "X" ];thenprint "Error: Invalid DN or DN does not exist"exit -1fi


# delete entries from the aclperm table that have null acldn’sprint Deleting entries from the aclperm table that have null acldn\’sdb2 "delete from aclperm where acldn like ’’ "

# get the maximum eid



#print $max_eids





cmd="db2 update src set aclsrc = $pdobj_acl_inherit where \eid in (select eid from objectclass \where eid > $i and eid < $j and (objectclass = ’SECMAP’ or \objectclass = ’SECUSER’ or objectclass = ’SECPOLICYDATA’))"

print $cmd$cmd

# delete entries from the aclperm table for this objectclasscmd="db2 delete from aclperm where eid in (select eid from objectclass \

where eid > $i and eid < $j and (objectclass = ’SECMAP’ or \objectclass = ’SECUSER’ or objectclass = ’SECPOLICYDATA’))"

print $cmd$cmd

cmd="db2 update src set aclsrc = $ldapuser_acl_inherit where \eid in (select eid from objectclass \where eid > $i and eid < $j and objectclass = ’INETORGPERSON’)"

print $cmd$cmd

# delete entries from the aclperm table for this objectclasscmd="db2 delete from aclperm where eid in (select eid from objectclass \

where eid > $i and eid < $j and objectclass = ’INETORGPERSON’)"print $cmd$cmd

i=$(( $j - 1 ))done

Here is the source for the fixacls3.sh script:#!/bin/ksh

# Script to fix up acls if different ACLs are desired for different# subtrees in the directory. Input includes the DN of the parent# of the subtree to be updated and the DN of an object from which# the ACL source is to come.## All PD objects within the specified subtree are updated to use# the secauthority=default object for their ACL source regardless# of what is specified on input.

# This script is intended to be used in the case where an incorrect choice is# made for suffix from which to inherit on the fixacls.sh script.## This script removes any aclperm table entries that may exist for the updated# objects.## The script also does a general cleanup of null entries in the aclperm table.



# The following defines the maximum number of updates that will be done atone time.# The larger this variable is the more disk space is used by the transactionlog.grouping=50000


usage(){print "Usage: $0 <subtree dn><acl source dn>"print " where"print " <subtree dn> is the DN of an object from which theACL is to come"print " <acl source dn> is the DN of an object from whichthe ACL is to come"print ""print " Note: DNs must be specified with in caps and no spaces"exit -1}

if [ "X$1" = "X" ] || [ "X$2" = "X" ];thenusagefi

subtree_dn=$1aclsrc_dn=$2

date



# get the eids for all suffixesdb2 select eid from ldap_entry where peid = -1 | \$AWK ’{if (index($0,"-")){getline;while ($1 != ""){print $1;getline}}}’ >eid.tmpsuf_eids=`cat eid.tmp`

# get the exclude clause for suffixesunset exclude_suf_clausefor i in $suf_eids;do

exclude_suf_clause=$exclude_suf_clause"and eid <> "$i" "done

# get the eid for the subtree DNdb2 "select ldap_entry.eid from ldap_entry where dn_trunc = ’$subtree_dn’" | \$AWK ’{if (index($0,"-")){getline;print $1}}’ >eid.tmpsubtree_eid=`cat eid.tmp`

if [ $subtree_eid = 0 ];thenprint "Error: Subtree DN does not exist in the database"print ""usagefi

# get the eid for the acl source DNdb2 "select ldap_entry.eid from ldap_entry where dn_trunc = ’$aclsrc_dn’" | \$AWK ’{if (index($0,"-")){getline;print $1}}’ >eid.tmp


aclsrc_eid=`cat eid.tmp`

if [ $aclsrc_eid = 0 ];thenprint "Error: The DN of the object to be used as the ACL source does notexist in the database"print ""usagefi



# delete entries from the aclperm table that have null acldn’sprint Deleting entries from the aclperm table that have null acldn\’sdb2 "delete from aclperm where acldn like ’’ " >update.tmp

print_if_not_empty(){grep SQL0100W update.tmp >/dev/nullif [ $? = 1 ];thencat update.tmpfi}

print_if_not_empty

# get the maximum eidprint Finding the maximum eid. This might take a minute or so.


#print $max_eids





# update all objects, including PD objects# It is too hard to distinguish all objects other than PD objects# The step after this one corrects the PD objects# for example, this picks up INETORGPERSON objectclassescmd="db2 update src set aclsrc = $aclsrc_eid where \

eid in (select deid from ldap_desc where aeid = $subtree_eid and \deid in (select eid from objectclass \where eid > $i and eid < $j $exclude_suf_clause))"

print $cmd$cmd >update.tmpprint_if_not_empty

cmd="db2 update src set aclsrc = $aclsrc_eid where \eid in (select deid from ldap_desc where aeid = $subtree_eid and \deid in (select eid from objectclass \where eid > $i and eid < $j $exclude_suf_clause and \(objectclass = ’SECMAP’ or objectclass = ’SECUSER’ or \objectclass = ’SECPOLICYDATA’)))"



# delete entries from the aclperm table for all updated objectscmd="db2 delete from aclperm where \

eid in (select deid from ldap_desc where aeid = $subtree_eid and \deid in (select eid from objectclass \where eid > $i and eid < $j $exclude_suf_clause))"


i=$(( $j - 1 ))done

rm -f update.tmp

date

sysstat_tune.shThe file system owner of this script should be the ldapdb2 user and the file systemgroup should be dbsysadm. The script must be run under the context of theldapdb2 user.

Here is the source of the sysstat_tune.sh script:#!/bin/ksh




do_tune(){

db2 -v "update sysstat.columns set COLCARD = 8 where tabname = ’$tabname’and COLNAME = ’$colname’"db2 -v "update sysstat.indexes set FIRSTKEYCARD = 8 where indname = ’$indname’"db2 -v "update sysstat.indexes set SEQUENTIAL_PAGES = 0 where indname = ’$indname’"db2 -v "update sysstat.indexes set NLEAF = 10 where indname = ’$indname’"db2 -v "update sysstat.indexes set NLEVELS = 2 where indname = ’$indname’"

}

do_tune2(){

db2 -v "update sysstat.columns set COLCARD = 8 where tabname = ’$tabname’and COLNAME = ’$colname’"

}

tabname=LDAP_DESCcolname=AEIDindname=LDAP_DESC_DEIDdo_tune

# note that SQL020306210707130 varies from machine to machine, so the actual value is# looked up belowtabname=LDAP_ENTRY


colname=EID#indname=SQL020306210707130indname=`db2 connect to ldapdb2 >/dev/null;db2 describe indexes for table ldap_entry \| grep SQL | $AWK ’{print $2}’`do_tune

tabname=MEMBERcolname=MEMBER_Tindname=MEMBERdo_tunetabname=MEMBERcolname=EIDdo_tune2

test_registry_perf.shThis script can be run under the context of any user. The file system owner andgroup must enable the user permission to execute the file.

Here is the source of the test_registry_per.sh script:#!/bin/ksh

# Restrictions:# This script can be run under the context of any user. It# requires write authority to the current directory for temporary# files.

ldap_host=$1ldap_pwd=$2user_suffix=$3test_user=$4test_user_password=$5

if [ "X$1" = "X" ] || [ "X$2" = "X" ] || [ "X$3" = "X" ] ||[ "X$4" = "X" ] || [ "X$5" = "X" ];thenprint "Usage: $0 <ldap_host><ldap_admin_pwd><user_suffix><test_user><test_user_password>"exit -1fi


# find the test user

ldapsearch -h $ldap_host -D cn=root -w $ldap_pwd -s sub -b "$user_suffix" \"(&(principalName=$test_user)(&(secAuthority=Default) \(objectClass=secUser)))" >$0.temp

cat $0.tempdn=`cat $0.temp | $AWK -F "," ’BEGIN{getline;print substr($0,index($0,$2))}’`suffix=`cat $0.temp | $AWK -F "," ’BEGIN{getline;print $NF}’`rm $0.temp

# test the users password

ldapsearch -h $ldap_host -D "$dn" -w "$test_user_password" -s base -b "$dn""objectclass=*" dn

# determine the group membership of the user


ldapsearch -h $ldap_host -D cn=root -w $ldap_pwd -s sub -b "$suffix" \" (|(member=$dn)(uniqueMember=$dn))" dn

# determine if small substree searches with non-unique filters are fast

ldapsearch -h $ldap_host -D cn=root -w $ldap_pwd -s sub -b "$dn""objectclass=*" dnldapsearch -h $ldap_host -D cn=root -w $ldap_pwd -s sub -b "$dn""objectclass=SecUser" dnldapsearch -h $ldap_host -D cn=root -w $ldap_pwd -s sub -b "$suffix""objectclass=SecGroup" dnldapsearch -h $ldap_host -D cn=root -w $ldap_pwd -s sub -b \"secauthority=default" "objectclass=SecGroup" dn

mk_test_users.sh#!/bin/ksh

# Script to create the ldif for test users

# Restrictions:# This script can be run under the context of any user. It does not# require write authority to the current directory.

start_user=$1end_user=$2

usage(){print "Usage: $0 <start user number><end user number> "exit -1}

if [[ "X$1" = "X" ]] || [[ "X$2" = "X" ]] thenusagefi

# set the password for all users here# Note that setting all passwords to the same value is not a good security policy.# It is better to initialize passwords to some initial secret only known to the# administrator and the user. Alternatively, set the password to some secret# not known to the user and force a password change in Access Manager by# setting the account to invalidpasswd=test1pass

# set the user suffix heresuffix="o=ibm,c=us"

# test user prefixtestuser_prefix=testuser

# iterate through user numbers generating ldif outputnum_users=$(( $end_user - $start_user + 1 ))user_num=$start_user

# create a function to print the LDIFprint_user(){

#The LDAP user ldif follows:

print dn: cn=$testuser_prefix$user_num,$suffixprint objectclass: inetOrgPersonprint objectclass: ePersonprint objectclass: organizationalPersonprint objectclass: personprint objectclass: topprint cn: $testuser_prefix$user_num


print sn: Perfprint userpassword: $passwdprint uid: $testuser_prefix$user_numprint

}

while [[ $user_num -le $end_user ]] do

print_user

user_num=$(( $user_num + 1 ))done

addpd_to_testusers_ldif.sh#!/bin/ksh

# Script to take an LDIF definition of many users and output the LDIF# for that original definition plus the LDIF to make that user a PD# user.

# This script must be customized based upon the input user LDIF# Some of the questions to be answered are# - where does the PD principalname come from# - what settings should be used for the following attributes:# secpwdvalid (true as in below?)# sechaspolicy (false as in below?)# secpwdlastchanged (see setting below)# secacctvalid (true as in below?)

# Input: standard input device# Output: standard output device


# set the password last change value here# It is a good idea to set this in the past and force a password change.# In this case, we are setting it to the future, so passwords are initially valid.secpwdlastchanged=20100419005109.0Z


# Figure out which uuidgen program to use

if [[ "X`which uuidgen | $AWK ’{print $2}’`" != "X" ]] && \[[ "X`which /opt/PolicyDirector/./sbin/pduuidgen | $AWK ’{print $2}’`" != "X" ]]

thenprint "$0 requires uuidgen from DCE package or"print " pduuidgen from the PD 3.8 package"print "The entire DCE or PD product is probably not necessary."print "Try just getting the following files and putting them in"print "appropriate places: (pd)uuidgen and libdce.so"exit -1fiif [[ "X`which uuidgen | $AWK ’{print $2}’`" = "X" ]] thenuuidgenp=uuidgenelseuuidgenp=/opt/PolicyDirector/./sbin/pduuidgenfi


$AWK -v uuidgenp="$uuidgenp" \-v secpwdlastchanged=$secpwdlastchanged ’

function print_pd_def(){

if (principalname != ""){

# dump out PD user ldif definition# first, generate the uuiduuidgenpn | getline uuidif (++num_uuidgenps >= pipe_size){# we ran out of uuids, so close the pipeclose(uuidgenpn)num_uuidgenps = 0}#print uuid

# print the PD definition ldif

print "dn: secAuthority=Default,"userdnprint "objectclass: secUser"print "objectclass: eUser"print "objectclass: cimManagedElement"print "objectclass: top"print "secauthority: Default"print "seclogintype: Default:LDAP"print "secpwdvalid: true"print "principalname: "principalnameprint "secuuid: "uuidprint "sechaspolicy: false"print "secpwdlastchanged: "secpwdlastchangedprint "secacctvalid: true"print ""print "dn: secUUID="uuid",cn=Users,secAuthority=Default"print "objectclass: secMap"print "objectclass: top"print "secdn: "userdnprint "secuuid: "uuidprint ""print "dn: cn=PolicyData,secAuthority=Default,"userdnprint "objectclass: secPolicyData"print "objectclass: top"print "cn: PolicyData"print "secpwdlastchanged: "secpwdlastchangedprint ""

principalname = ""}

}

BEGIN{

pipe_size = 10000uuidgenpn = uuidgenp" -n "pipe_size

}

# main(){

if ($1 == "dn:" && notfirstdn){

print_pd_def()

userdn = substr($0, 5)


} else {if ( $1 == "dn:") {notfirstdn = 1userdn = substr($0, 5)

} else if ($1 == "uid:"){

# note: using uid field for# PD principalnameprincipalname = substr($0,index($0,$2))}

}

# echo original ldifprint $0

} END {

if (notfirstdn){print ""print_pd_def()}

# hack: clean the pipe to prevent "Broken Pipe" errorswhile (++num_uuidgenps < pipe_size){uuidgenpn | getline uuid}

}’

incremental_bulkload.sh#!/bin/ksh

# Script to break up an input stream of LDIF data into specified# numbers of LDAP objects (dn’s) and invoke the LDAP bulkload# utility to load the data.## Input - Standard input device containing the LDIF data to be# bulk loaded## Restrictions:# This script must be run under the context of the root user. It# requires write authority to the current directory for temporary# files.

# Warning: Do not use this script to bulk load large groups. A# large group is one with many members for its member attribute.# Use the group LDAP add script for that purpose.## This script divides the input data into increments that are# separately loaded. This keeps the space for the temporary# LDIF and DB2 load files to a managable size.## The script can be directed to stop at the next invokation of# bulkload by writing "0" to a control file by the name of# "continue.bulkload".## The script records the dn’s for first and last objects loaded in# any increment into a log file of the scripts activities. This# can be used to aid restarting the script at the last known point.## Disk requirements vary depending upon the LDIF input and


# the number of objects added in each incremental load.# Disk requirements:# - Temporary LDIF data: size of the LDIF for any given incremental# load. The number of objects in an incremental load is controlled# by the increment environment variable. For an incrment variable# of 400000 and typical Policy Director user data, the temporary# ldif data storage requirement is 100MB.# - 3 times the temporary LDIF data for DB2 load data.# For Policy Director user data and a 400000 increment, the storage# requirement is about 400MB

# Increment variable# Note for PD users, set increment to 4 times the number of# PD users desired per incrementincrement=2000100 # a little over half a million PD users (2M LDAP objects)

usage(){print ""print Usage: "$0 <drop_indexes|with_indexes>"print ""exit -1}

if [ "X$1" = "X" ];thenusagefiif [ $1 != "drop_indexes" ] && [ $1 != "with_indexes" ];thenusagefi

export logfile=inc_bulk.outrm -f $logfile #remove log file

# File used for temporary LDIF data# It is not cleaned up at the end. Do it manually.export ldif_file=bulkload.ldif

# ldapimport directory (where DB2 load files go)# This directory will be deleted and recreated.# It is not cleaned up at the end. Do it manually.# Note: this is an environment variable used by the# bulkload utility.export LDAPIMPORT=`pwd`/ldapimport

# Other environment variables used by the bulkload# utilityexport SCHEMACHECK=NOexport ACLCHECK=NOexport REMOVETMP=NO

# clean up the any previous import directoryrm -fr $LDAPIMPORT #comment out if REMOVETMP=YESmkdir $LDAPIMPORT


# Bulkload help:# usage: bulkload [-i inputfile] [-f configfile] [-c <yes|no>] [-a <yes|no>]# -i: ldif file to load.# -f: configuration file.# -c: create indexes?# -a: check for attribute aliases?


# kill slapd if runningslapd_pid=`ps -ef | grep slapd |$AWK ’{if ($1 == "ldap")print $2}’`if [[ "X$slapd_pid" != "X" ]] thenprint "$0: killing slapd"kill $slapd_pidfi

echo 1 >continue.bulkload

# main

# Create a temporary ldif of the next increment# number of ldap objects read from the input# device and invoke the bulkload utility

rm -f $ldif_file

$AWK -v ldif_file=$ldif_file \-v index_option=$1 \-v increment=$increment ’

function continue_check(){

getline < "continue.bulkload"if ($1 != 1){exit}close ("continue.bulkload")}

function invoke_bulkload(){

continue_check()

# Invoke the bulkload utility

system("echo start time bulkload parse: `date` 2>&1 | tee -a $logfile")

# clean up the any previous import directorysystem("rm -fr $LDAPIMPORT #comment out if REMOVETMP=YES")system("mkdir $LDAPIMPORT")

# set the DB2 config parameters for the parse phase##system("su - ldapdb2 -c \"db2 update database configuration for ldapdb2 using##UTIL_HEAP_SZ 5000\"")# Next two lines need customization# 3.2.1#system("su - ldapdb2 -c \"db2 update database configuration for ldapdb2##using BUFFPAGE 128000\"")# 3.2.2##system("su - ldapdb2 -c \"db2 connect to ldapdb2; \## db2 alter bufferpool ibmdefaultbp size 100000; \## db2 alter bufferpool ldapbp size 25000; \## db2 terminate; \## \"")##system("su - ldapdb2 -c db2 force applications all")##system("sleep 3")##system("su - ldapdb2 -c db2stop")##system("sleep 1")##system("su - ldapdb2 -c db2start")##system("sleep 1")

system("ACTION=PARSEONLY bulkload -i $ldif_file -a no 2>&1 | tee -a $logfile")# this file grows with each parsesystem("rm -f /tmp/slapd.errors")system("rm -f /var/ldap/slapd.errors")


continue_check()

system("echo start time bulkload load: `date` 2>&1 | tee -a $logfile")

if (index_option == "with_indexes"){# For loading without dropping indexessystem("rm -f /usr/ldap/etc/bulkload_status*") #for AIXsystem("rm -f /opt/IBMldaps/etc/bulkload_status*") # for Solaris}

# set the DB2 config parameters for the db2 load phase# Next two lines need customization# 3.2.1#system("su - ldapdb2 -c \"db2 update database configuration for ldapdb2 using##BUFFPAGE 16000\"")# 3.2.2##system("su - ldapdb2 -c \"db2 connect to ldapdb2; \## db2 alter bufferpool ibmdefaultbp size 49800; \## db2 alter bufferpool ldapbp size 400; \## db2 terminate; \## \"")

##system("su - ldapdb2 -c \"db2 update database configuration for ldapdb2 using##UTIL_HEAP_SZ 5000\"")##system("su - ldapdb2 -c db2 force applications all")##system("sleep 3")##system("su - ldapdb2 -c db2stop")##system("sleep 1")##system("su - ldapdb2 -c db2start")##system("sleep 1")

# following two lines are for customizing the load script# they differ depending on the LDIF input#system("cp -p $LDAPIMPORT/ldapdb2.ddl ldapdb2.ddl.save")#system("cp -p ldapdb2.ddl $LDAPIMPORT/ldapdb2.ddl")

if (index_option == "drop_indexes"){# For load with dropping indexessystem("ACTION=LOADONLY bulkload -i $ldif_file -a no 2>&1 |tee -a $logfile")} else {# For load with indexessystem("su - ldapdb2 -c \"cd $LDAPIMPORT;ldapdb2.ddl 2>&1\" |tee -a $logfile")}

system("rm -f "ldif_file)

continue_check()}

BEGIN{system("echo start time create temporary ldif: `date` 2>&1 |tee -a $logfile")}{# put the line in the temp ldif fileprint $0 > ldif_file

# if this is a dn lineif ($1 == "dn:"){

dn_line = $0

# save the first dnif (!not_first){


not_first = 1system("echo first "dn_line" | tee -a $logfile")}

# check for and save the last dndn_count++if (dn_count >= increment){last_dn = 1system("echo last "dn_line" | tee -a $logfile")}}

# if working on the last dn, find the null line that# terminates it and invoke bulkloadif (last_dn && $0 == ""){not_first = 0last_dn = 0dn_count = 0

close(ldif_file)

invoke_bulkload()

system("echo start time create temporary ldif: `date` 2>&1 |tee -a $logfile")}}END{

# bulkload any left over dnsif (not_first){system("echo last "dn_line" | tee -a $logfile")close(ldif_file)invoke_bulkload()}

}’

echo stop time: `date` 2>&1 | tee -a $logfile

mk_test_group_ldif.sh#!/bin/ksh

# Sript to create the ldif for a test LDAP group with# many users

# Restrictions:# This script can be run under the context of any user. It does not# requires write authority to the current directory.

cmd=$1start_user=$2end_user=$3

usage(){print "Usage: $0 <create | add><start user number><end user number>"exit -1}

if [[ "X$1" = "X" ]] || [[ "X$2" = "X" ]] || [[ "X$3" = "X" ]];thenusagefi

if [[ $cmd != "create" ]] && [[ $cmd != "add" ]];thenusagefi


# set the group name heretestgroup=testgroup1

# set the user suffix heresuffix="o=ibm,c=us"

# test user prefixtestuser_prefix=testuser


$AWK -v testgroup=$testgroup \-v suffix=$suffix \-v testuser_prefix=$testuser_prefix \-v cmd=$cmd \-v start_user=$start_user \-v end_user=$end_user \

’BEGIN{

if (cmd == "create"){

print "dn: cn="testgroup","suffixprint "objectclass: accessGroup"print "objectclass: top"print "cn: "testgroup

} else {

print "dn: cn="testgroup","suffixprint "changetype: modify"print "add: member"

}

for (i=start_user; i<=end_user; i++){

print "member: cn="testuser_prefix""i","suffix}}’

addpd_to_groups_ldif.sh#!/bin/ksh

# Script to take an LDIF definition of one or more groups and other# ldif data and add the LDIF data to make that or those groups# PD groups. Any non-group LDIF is passed along the output# stream unchanged.

# This script must be customized based upon the LDIF input# Some of the questions to be answered are# - Where does the PD group name come from? PD stores the group# name in the "cn:" attribute of the SecGroup object. A# common solution is to name the group object using the# "cn:" attribute and use the group object name as the# PD group name. This is done in this script.# - Should ACLs be created to protect PD objects? Such ACLs# are created by pdadmin. This script does create these# ACLs.

# Input: standard input device# Output: standard output device




# Figure out which uuidgen program to use

if [[ "X`which uuidgen | $AWK ’{print $2}’`" != "X" ]] && \[[ "X`which /opt/PolicyDirector/./sbin/pduuidgen | $AWK ’{print $2}’`" != "X" ]]

thenprint "$0 requires uuidgen from DCE package or"print " pduuidgen from the PD 3.8 package"print "The entire DCE or PD product is probably not necessary."print "Try just getting the following files and putting them in"print "appropriate places: (pd)uuidgen and libdce.so"exit -1fiif [[ "X`which uuidgen | $AWK ’{print $2}’`" = "X" ]] thenuuidgenp=uuidgenelseuuidgenp=/opt/PolicyDirector/./sbin/pduuidgenfi

# Have the uuidgen program create 1m uuids at a timeuuidgenp="$uuidgenp -n 1000000"

$AWK -v uuidgenp="$uuidgenp" ’

function print_pd_def(){

# If this is a group, create the PD group LDIFif (is_group){

# dump out PD group ldif definition# first, generate the uuidif (uuidgenp | getline uuid <= 0){# we ran out of uuids, so start# another uuidgenclose(uuidgenp)uuidgenp | getline uuid}

# Create the PD group LDIF

print "dn: secAuthority=Default,"save_dnprint "objectclass: secGroup"print "objectclass: top"print "secauthority: Default"print "cn: "groupnameprint "secuuid: "uuidprint "sechaspolicy: false"print "aclpropagate: TRUE"print "aclentry: group:CN=REMOTE-ACL-USERS,CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:normal:rsc"print "aclentry: group:CN=IVACLD-SERVERS,CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:normal:rsc"print "aclentry: group:CN=SECURITYGROUP,SECAUTHORITY=DEFAULT:object:ad:normal:rwsc:sensitive:rwsc:critical:rwsc"print ""print "dn: secUUID="uuid",cn=Groups,secAuthority=Default"print "objectclass: secMap"


print "objectclass: top"print "secdn: "save_dnprint "secuuid: "uuidprint ""}}

# main(){

if ($1 == "dn:" && notfirstdn){

print_pd_def()

save_dn = substr($0, 5)is_group = 0

} else {if ( $1 == "dn:") {notfirstdn = 1save_dn = substr($0, 5)

} else if ($1 == "objectclass:" && $2 == "accessGroup") {

is_group = 1

} else if ($1 == "cn:"){

# note: using uid field for# PD principalnamegroupname = $2}}

# echo original ldifprint $0

} END {

if (notfirstdn){print ""print_pd_def()}}’

incremental_group.sh#!/bin/ksh

# The primary purpose of this script is to break up an input# stream of LDIF data containing one or more large group# objects. A large group object is defined as one having# a large number of members. The LDIF is broken up into# the creation of the group object with no members followed# by one or more modifications to add its members.

# The reason for creating large groups in this way is to work# around a couple of problems in LDAP:# - For LDAP 3.2.1, creating a large group in one operation# results in an inefficient storage of that group in DB2,# resulting in performance problems when LDAP accesses that# group.# - creating a large group requires a large amount of# storage in the LDAP directory holding DB2 tablespace1# (e.g. in ldapdb2 user’s home directory). This space


# is used for the transaction log that is used to back# out the request in case it fails. If this storage is# exceeded, the database is left corrupted and must# be restored from a previous back up.## The secondary function of this script is to use ldapadd# to load whatever LDIF is in the input stream.## Input - Standard input device containing the LDIF data to be# loaded## Restrictions:# This script can be run under the context of any user. It# requires write authority to the current directory for temporary# files.

# Warning: Do not use this script to load a large number of# LDAP objects. The bulkload facility is much faster for# that purpose. Note this is different from a single object# with a large number of members, which this script is# designed to handle.

# This script divides large groups into increments that are# separately loaded. This keeps the space for the db2 transaction# log to a managable size.## The script can be directed to stop at the next invokation of# of ldapadd or the next "dn" by writing "0" to a control file# by the name of "continue.groupload".## The script records the names of first and last members added# to a group in any increment. This activity is logged to a file.# The log file can aid in restarting the script at the last known# point.## Disk requirements vary depending upon the LDIF input and# the number of members added per increment.# Disk requirements:# - tablespace in the LDAP instance owners home directory: TBD.# expressed in approximate number of bytes per member in an# increment. For example, for 10K members, the storage is# about TBD.# This directory also stores the temporary transaction log

# Increment variable# This is the number of members to be added at one time.increment=10000

# LDAP admin passwordldap_pwd=fsaustin

export logfile=inc_group.outrm -f $logfile #remove log file


# Make sure slapd running for ldapaddprint "$0: checking for slapd"slapd_pid=`ps -ef | grep slapd |$AWK ’{if ($1 == "ldap")print $2}’`if [[ "X$slapd_pid" = "X" ]] thenprint "$0: ERROR - slapd is not running. Please start it and try again."exit -1


fi

echo 1 >continue.groupload

# main

$AWK -v increment=$increment \-v ldap_pwd=$ldap_pwd ’

function ldapadd_pipe_write(cmd){

if (debug == 0){print cmd | pipe_cmd} else {print cmd >"ldapadd_debug.log"}}

function ldapadd_pipe_close(){

if (debug == 0){close(pipe_cmd)} else {print "close" >"ldapadd_debug.log"}}

function cleanup(){

if (working_on_group) {system("echo last "last_member" | tee -a $logfile")}system("echo last "dn_line" | tee -a $logfile")ldapadd_pipe_close()system("echo end time ldapadd: `date` 2>&1 | tee -a $logfile")

}

function continue_check(){

getline < "continue.groupload"if ($1 != 1){cleanup()exit}close ("continue.groupload")}

function finish_and_more_member_check(){

# Finish out the possibly partial ldif for this group# object.# If this is the first time called for this group,# it causes the group object to be created.# The group object contains a single member, namely# the first member in the ldif.# If this is the subsequent time called for this# group, it finishes out the incremental load# of members for that group.

# If we just completed an incremental load of members,# close out the ldapadd and take a timing

if (mem_count == increment) {

ldapadd_pipe_write("")ldapadd_pipe_close()


not_first = 0

# print out a time stampsystem("echo end time ldapadd: `date` 2>&1 | tee -a $logfile")}

working_on_group = 0

# If we are still in the middle of a dn definition# determine if the definition has ended.

if ($1 != "") {

# Check to see if there are any other members in# the group. We have a group, but it could have had# only a single member or the last incremental# add could have finished out the entire group.

getlineline_save = $0if ( $1 != "") {

attr = substr($1,1,length($1)-1)

# Start the ldif to add the remaining member(s) to# the group.ldapadd_pipe_write("")ldapadd_pipe_write(dn_line)ldapadd_pipe_write("changetype: modify")ldapadd_pipe_write("add: "attr)

if ( $1 == "member:") {

last_member = line_savecontinue_check()

system("echo first "line_save" | tee -a $logfile")

working_on_group = 1mem_count = 1}}ldapadd_pipe_write(line_save)}}

BEGIN{system("echo start time ldapadd: `date` 2>&1 | tee -a $logfile")pipe_cmd = "ldapadd -D cn=root -w "ldap_pwddebug = 0}{# process a line of ldif

save_line = $0if ($1 == "dn:"){continue_check()}$0 = save_line

# send the line of ldif to ldapaddldapadd_pipe_write(save_line)

# if this is a dn lineif ($1 == "dn:"){


dn_line = $0

# save the first dnif (!not_first){not_first = 1system("echo first "dn_line" | tee -a $logfile")}

# get the next linegetline

# If this is not a changetype line, then add changetype.# Note: ldapadd does not seem to handle some dns with changetype# and others without

if ($1 != "changetype:") {

ldapadd_pipe_write("changetype: add")

}

# send the line of ldif to ldapaddldapadd_pipe_write($0)

} else if (working_on_group) {

# working on a group

# check for end of member definitionif ($1 != "member:") {

system("echo last "last_member" | tee -a $logfile")if ($1 == "") {finish_and_more_member_check()}} else {last_member = $0# increment the number of members in this# addition to the groupmem_count ++

# if we have reached the max number per# incrementif ( mem_count == increment) {

system("echo last "$0" | tee -a $logfile")

# Check to see if there are any other membersfinish_and_more_member_check()}}

} else {

# This is ldif data, but we do not know if# it is for a group yet

# member attribute means this is a groupif ( $1 == "member:") {

system("echo group "dn_line" | tee -a $logfile")system("echo first "$0" | tee -a $logfile")system("echo last "$0" | tee -a $logfile")

# Check to see if there are any other membersfinish_and_more_member_check()}


}

}END{

cleanup()

}’


Appendix B. Notices

This information was developed for products and services offered in the U.S.A.

IBM® may not offer the products, services, or features discussed in this documentin other countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user’s responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not give youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chome, Minato-kuTokyo 106-0032, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express orimplied warranties in certain transactions, therefore, this statement may not applyto you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Websites. The materials at those Web sites are not part of the materials for this IBMproduct and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way itbelieves appropriate without incurring any obligation to you.


Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758U.S.A.

Such information may be available, subject to appropriate terms and conditions,including in some cases, payment of a fee.

The licensed program described in this information and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement, or any equivalent agreementbetween us.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

All statements regarding IBM’s future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrate programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment toIBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operatingplatform for which the sample programs are written. These examples have notbeen thoroughly tested under all conditions. IBM, therefore, cannot guarantee orimply reliability, serviceability, or function of these programs. You may copy,modify, and distribute these sample programs in any form without payment toIBM for the purposes of developing, using, marketing, or distributing applicationprograms conforming to IBM’s application programming interfaces.

If you are viewing this information softcopy, the photographs and colorillustrations may not appear.

TrademarksThe following terms are trademarks or registered trademarks of InternationalBusiness Machines Corporation in the United States, other countries, or both:


AIXDB2IBMIBM logoOS/390SecureWayTivoliTivoli logoUniversal DatabaseWebSpherez/OSzSeries

Lotus is a registered trademark of Lotus Development Corporation and/or IBMCorporation.

Domino is a trademark of International Business Machines Corporation and LotusDevelopment Corporation in the United States, other countries, or both.

Microsoft and Windows are trademarks of Microsoft Corporation in the UnitedStates, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States and other countries.

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

Other company, product, and service names may be trademarks or service marksof others.

Appendix B. Notices 87

Printed in U.S.A.

GC32-0846-00

IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC32-0846-00/… · ·...

Documents

Transcript of IBM Tivoli Access Managerpublib.boulder.ibm.com/tividd/td/ITAME/GC32-0846-00/… · ·...