IBM System Storage DS8000: LDAP Authentication - IBM Redbooks

Front cover 

IBM System Storage DS8000: 

LDAP Authentication 

Implement LDAP authentication 

for the DS8000 

Configure the required Tivoli 

Productivity Center v4.1 

Benefit from single 

sign-on 

Bertrand Dufrasne 

Marcus Gorzellik 

Gabor Penzes 

ibm.com/redbooks Redpaper

International Technical Support Organization 

IBM System Storage DS8000: LDAP Authentication 

May 2009 

REDP-4505-00

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

First Edition (May 2009) 

This edition applies to the IBM System Storage DS8000 with Licensed Machine Code 5.4.20.xx (code bundles 

64.20.x.x). 

© Copyright International Business Machines Corporation 2009. All rights reserved. 

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule 

Contract with IBM Corp.

Contents 

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v 

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi 

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 

The team that wrote this paper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 

Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii 

Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii 

Chapter 1. LDAP authentication for DS8000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.1 DS8000 basic user management and access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

1.2 Directory Services and LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

1.3 Overview of LDAP-based authentication for the DS8000 . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.4 Benefits for DS8000 administrators and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

Chapter 2. Implementing LDAP for the DS8000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.1 Test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.2 Installing the LDAP servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.3 Installing and configuring the Tivoli Storage Productivity Center servers . . . . . . . . . . . 13 

2.4 Creating the certificates and the truststore file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.4.1 Creating the certificate and the truststore file on TPC server1 . . . . . . . . . . . . . . . 13 

2.4.2 Setting up TPC server2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.4.3 Copying the truststore file from TPC server1 to TPC server2. . . . . . . . . . . . . . . . 22 

2.5 Configuring the DS8000 for LDAP authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

Chapter 3. User, group, and role administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

3.1 DS8000 to LDAP groups mappings using the DS GUI . . . . . . . . . . . . . . . . . . . . . . . . . 34 

3.2 DS8000 to LDAP groups mappings using the DS CLI . . . . . . . . . . . . . . . . . . . . . . . . . 35 

3.3 User administration for Tivoli Storage Productivity Center servers. . . . . . . . . . . . . . . . 36 

3.3.1 Tivoli Storage Productivity Center roles to LDAP group mappings. . . . . . . . . . . . 36 

Appendix A. Installing Tivoli Storage Productivity Center 4.1 on 

Windows Server 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

Appendix B. Configuring Tivoli Storage Productivity Center for DS8000 LDAP 

authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

B.1 Securing the administration, applications, and infrastructure settings . . . . . . . . . . . . . 52 

B.2 Configuring federated repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

B.3 Adding a base entry to a realm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

B.4 Setting additional properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

B.5 Managing users and groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

Appendix C. Installing Tivoli Directory Server v6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

C.1 Installing the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

C.2 Configuring the server instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 

Appendix D. Installing openLDAP in a SUSE Linux environment . . . . . . . . . . . . . . . . 73 

D.1 Installing the required LDAP packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 

D.2 Configuring the LDAP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

D.3 Configuring the LDAP client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

© Copyright IBM Corp. 2009. All rights reserved. iii

Appendix E. LDAP structure overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

How to get Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 

iv IBM System Storage DS8000: LDAP Authentication

Notices 

This information was developed for products and services offered in the U.S.A. 

IBM may not offer the products, services, or features discussed in this document in other countries. Consult 

your local IBM representative for information on the products and services currently available in your area. Any 

reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, 

program, or service may be used. Any functionally equivalent product, program, or service that does not 

infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to 

evaluate and verify the operation of any non-IBM product, program, or service. 

IBM may have patents or pending patent applications covering subject matter described in this document. The 

furnishing of this document does not give you any license to these patents. You can send license inquiries, in 

writing, to: 

IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A. 

The following paragraph does not apply to the United Kingdom or any other country where such 

provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION 

PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR 

IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, 

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of 

express or implied warranties in certain transactions, therefore, this statement may not apply to you. 

This information could include technical inaccuracies or typographical errors. Changes are periodically made 

to the information herein; these changes will be incorporated in new editions of the publication. IBM may make 

improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time 

without notice. 

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any 

manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the 

materials for this IBM product 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 it believes appropriate without incurring 

any obligation to you. 

Information concerning non-IBM products was obtained from the suppliers of those products, their published 

announcements or other publicly available sources. IBM has not tested those products and cannot confirm the 

accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the 

capabilities of non-IBM products should be addressed to the suppliers of those products. 

This information contains examples of data and reports used in daily business operations. To illustrate them 

as completely as possible, the examples include the names of individuals, companies, brands, and products. 

All of these names are fictitious and any similarity to the names and addresses used by an actual business 

enterprise is entirely coincidental. 

COPYRIGHT LICENSE: 

This information contains sample application programs in source language, which illustrate programming 

techniques on various operating platforms. You may copy, modify, and distribute these sample programs in 

any form without payment to IBM, for the purposes of developing, using, marketing or distributing application 

programs conforming to the application programming interface for the operating platform for which the sample 

programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, 

cannot guarantee or imply reliability, serviceability, or function of these programs. 

© Copyright IBM Corp. 2009. All rights reserved. v

Trademarks 

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines 

Corporation in the United States, other countries, or both. These and other IBM trademarked terms are 

marked on their first occurrence in this information with the appropriate symbol (® or ), indicating US 

registered or common law trademarks owned by IBM at the time this information was published. Such 

trademarks may also be registered or common law trademarks in other countries. A current list of IBM 

trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml 

The following terms are trademarks of the International Business Machines Corporation in the United States, 

other countries, or both: 

AIX® 

DB2® 

Domino® 

DS6000 

DS8000® 

Enterprise Storage Server® 

i5/OS® 

IBM® 

Lotus® 

Redbooks® 

Redbooks (logo) ® 

Redpaper 

The following terms are trademarks of other companies: 

vi IBM System Storage DS8000: LDAP Authentication 

System Storage 

Tivoli® 

WebSphere® 

z/OS® 

SUSE, the Novell logo, and the N logo are registered trademarks of Novell, Inc. in the United States and other 

countries. 

Interchange, Red Hat, and the Shadowman logo are trademarks or registered trademarks of Red Hat, Inc. in 

the U.S. and other countries. 

Java, Solaris, Sun, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United 

States, other countries, or both. 

Active Directory, Microsoft, Windows Server, Windows, and the Windows logo are trademarks of Microsoft 

Corporation in the United States, other countries, or both. 

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

Linux is a trademark of Linus Torvalds in the United States, other countries, or both. 

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

Preface 

Starting with release 4.2, the IBM® System Storage DS8000® series offers the ability to 

replace the locally based user ID and password administration with a centralized directory 

based approach. This release also allows a single sign-on capability for multiple DS8000 

servers and possibly other servers in your environment. 

This IBM Redpaper publication helps DS8000 storage administrators understand the 

concepts and benefits of directories. It provides information that is required for implementing a 

DS8000 authentication approach based on the Lightweight Directory Access Protocol (LDAP). 

The team that wrote this paper 

This paper was produced by a team of specialists from around the world working with the 

International Technical Support Organization (ITSO). 

Bertrand Dufrasne is an IBM Certified Consulting IT Specialist and Project Leader for IBM 

System Storage disk products at the ITSO in San Jose, CA. He has worked at IBM in various 

IT areas, has written many IBM Redbooks® publications, and has developed and taught 

technical workshops. Before joining the ITSO, he worked for IBM Global Services as an 

Application Architect in the retail, banking, telecommunications, and healthcare industries. He 

holds a master degree in electrical engineering from the Polytechnic Faculty of Mons 

(Belgium). 

Marcus Gorzellik is an IBM Certified Specialist for High End Disk Solutions, working for the 

High End Storage System Support Center in Mainz, Germany. He has 12 years of experience 

in PC/server and network hardware support. For the past four years, he has provided support 

for Customer and Customer Service representatives with High End Disk Subsystems, such 

as the IBM System Storage DS8000, DS6000, and Enterprise Storage Server® (ESS). His 

focus is open systems attachment of high-end storage including AIX®, Microsoft® 

Windows®, and Linux®. 

Gabor Penzes is a Test Engineer and System Administrator, working with DS8000 servers in 

Vac, Hungary. His focus is storage and highly available cluster systems on AIX and Linux 

platforms. He has more than 10 years of experience in planning, developing, and supporting 

UNIX®-based storage and server system architectures and networks. Gabor holds a degree 

in information engineering from the University of Pecs (Hungary). 

A special thank you to the following people: 

► John Bynum of IBM U.S. 

► Lisa Martinez of the IBM Tucson lab for providing equipment in support of this project 

► Jens Wissenbach of IBM Germany for his preliminary work, on which we based some 

parts of this paper 

© Copyright IBM Corp. 2009. All rights reserved. vii

Thanks to the following people for their contributions to this project: 

Sondra Ashmore, Kevin Gibble, Rakesh Jain, Markus Navarro, Thuan Q. Nguyen, and Kavita 

Shah of IBM U.S. 

Uwe Dubberke and Gerhard Pieper of IBM Germany 

Brian Sherman of IBM Canada 

Become a published author 

Join us for a two- to six-week residency program! Help write a book dealing with specific 

products or solutions, while getting hands-on experience with leading-edge technologies. You 

will have the opportunity to team with IBM technical professionals, Business Partners, and 

Clients. 

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you 

will develop a network of contacts in IBM development labs, and increase your productivity 

and marketability. 

Find out more about the residency program, browse the residency index, and apply online at: 

ibm.com/redbooks/residencies.html 

Comments welcome 

Your comments are important to us! 

We want our papers to be as helpful as possible. Send us your comments about this paper or 

other IBM Redbooks in one of the following ways: 

► Use the online Contact us review Redbooks form found at: 

ibm.com/redbooks 

► Send your comments in an e-mail to: 

redbooks@us.ibm.com 

► Mail your comments to: 

IBM Corporation, International Technical Support Organization 

Dept. HYTD Mail Station P099 

2455 South Road 

Poughkeepsie, NY 12601-5400 

viii IBM System Storage DS8000: LDAP Authentication

1 

Chapter 1. LDAP authentication for DS8000 

Starting with Licensed Machine Code (LMC) level 5.4.20.xx, the DS8000 offers the capability 

to use Directory Services-based user authentication. This capability relies on unique features 

of the Tivoli® Storage Productivity Center 4.1 and the Tivoli Integrated Portal, in conjunction 

with the Lightweight Directory Access Protocol (LDAP). 

Previous versions of the DS8000 code only supported local user management (basic user 

management). Maintaining local repositories of users and their permissions is simple and 

convenient when only dealing with a small number of users and a small number of DS8000 

servers or other systems. However, as the number of users and interconnected systems 

grows, authentication management quickly becomes difficult and time consuming. 

The benefits of a centralized user management approach can be substantial when 

considering the size and complexity of the overall IT environment. In this chapter, we review 

some of the benefits of this approach. Although the benefits from LDAP are substantial, you 

must also evaluate the substantial planning effort and complexity of deploying centralized 

Directory Services, if they are not already in place. 

We also briefly review the DS8000 local user management and user access methods. In 

addition, we provide an overview of the new LDAP-based authentication, the technology 

used, and the potential benefits. 

© Copyright IBM Corp. 2009. All rights reserved. 1

1.1 DS8000 basic user management and access 

Basic user management refers to the local user management approach. Until the availability of 

License Machine Code 5.42.xx.xx, basic user management was the only supported 

capability. In this section, we review the characteristics of the local user management 

approach. 

Basic user management for the DS8000 is based on the definition of user IDs, passwords, 

roles, and permissions. This information is stored in a user repository and maintained locally 

at the DS8000 Hardware Management Console (HMC). The user repository is specific to a 

particular DS8000 and cannot be shared with other DS8000 servers in the enterprise. 

Consequently if the same individuals must be administrators and users of multiple DS8000 

servers within the enterprise, their user IDs, passwords, and roles must be separately created 

and individually maintained for each DS8000 server. 

The Enterprise Storage System Network Interface (ESSNI) server, which resides on the HMC 

(Figure 1-1), is responsible for managing the security repository and establishing mappings 

between users and their role and permissions. The ESSNI server is also responsible for 

authenticating users. 

An administrator user ID is preconfigured during the installation of the DS8000 with the 

following defaults: 

User ID admin 

Password admin 

Whenever a user is added, a password is intially assigned by the administrator. At the first 

sign-on, users must change their password. The user ID is deactivated if an invalid password 

is entered and the number of attempts is more than the limit defined by the administrator as 

part of the security settings. 

The password for each user account is forced to adhere to the following rules: 

► The length of the password must be between 6 and 16 characters. 

► The password must begin and end with a letter. 

► The password must have at least five letters. 

► The password must contain at least one number. 

► The password cannot be identical to the user ID. 

► The password cannot be a previous password. 

General password settings include the time period in days after which passwords expire and a 

number that identifies the number of failed logins that are allowed. 

The user management is restricted to the following predefined user roles. 

Administrator Allows access to all storage management console server service 

methods and all storage image resources. 

Logical operator Allows access to service methods and resources that relate to logical 

volumes, hosts, host ports, logical subsystems, and volume groups, 

excluding security methods. 

Physical operator Allows access to physical configuration service methods and 

resources, including Storage Complex, Storage Image, Rank, Array, 

and Extent Pool objects. 

Copy Services operator 

Allows access to all Copy Services service methods and resources, 

excluding security methods. 

2 IBM System Storage DS8000: LDAP Authentication

Monitor Allows access to list and show commands. It provides access to all 

read-only, nonsecurity management console server service methods 

and resources. 

No access Does not allow access to any service method or storage image 

resources. By default, this user group is assigned to any user account 

in the security repository that is not associated with any other user 

group. 

Communications between the DS8000 HMC and the administrative clients are managed by a 

client/server connection between the DS8000 HMC ESSNI server and the host running a 

ESSNI client. Regardless of the connection type, all connections must authenticate with a 

user and password against the ESSNI server that is running on the HMC. 

Figure 1-1 illustrates the different possible communications between administrative clients 

and the DS8000 HMC, as well as the communication flow. 

Browser 

TCP/IP 

Remote desktop 

TPC Host 

or SSPC 

Directly 

Authentication 

without LDAP 

TPC 

TPC GUI 

DS GUI 

ESSNI 

Client 

DS CLI 

Client 

TPC GUI 

DS8000 HMC 1 

ESSNI 

Server 


ESSNI 

Server 

Figure 1-1 Communication between DS8000 HMC and administrative clients 

DS 8000 

Complex 1 

DS 8000 

Complex 2 

An administrative client has the following possible connections: 

► Connection through the System Storage Productivity Center (SSPC) 

The ESSNI client is part of the Tivoli Storage Productivity Center running at the SSPC. 

► Connection from a browser connected to the SSPC or Tivoli Storage Productivity Center 

on any server 

The ESSNI client is part of the DS graphical user interface (GUI) that is started within a 

Java applet during the connection. 

► Connection from a separate Tivoli Storage Productivity Center workstation connected to 

the HMC 

The ESSNI client is part of the Tivoli Storage Productivity Center running on this 

workstation. 

TCP/IP 

User repository 

User repository 

User authentication 

is managed by the 

ESSNI server 

regardless of type 

of connection 

Chapter 1. LDAP authentication for DS8000 3

► Connection by using Microsoft Windows Remote Desktop to the SSPC 

The ESSNI client is part of the Tivoli Storage Productivity Center running on the SSPC. 

► Connection directly to the HMC by using DS command line interface (CLI) 

The ESSNI client is part of the DS CLI. 

User management and administration are done by using the DS GUI (through the SSPC) or 

the DS CLI. 

To work with user administration: 

1. Sign on to the DS GUI. 

2. From the selection menu on the left (Figure 1-2), select Real-time manager → Monitor 

System and click User Administration. 

3. In the Basic Authentication User Administration panel on the right, click the Select action 

list and select Add user. 

Figure 1-2 Adding a user by using the DS GUI 


4. In the Add/Modify User window (Figure 1-3), add a user by entering the user ID, the 

temporary password, and the role. The role decides the type of activities that can be 

performed by this user. You can temporarily deactivate the user ID by selecting No access 

(only). 

Figure 1-3 Adding a user and selecting the role 

You can also use the DS CLI to perform user administration tasks. Example 1-1 illustrates use 

of the mkuser command to add a new user, named csadmin. 

Example 1-1 Adding a user by using the DS CLI 

dscli>mkuser -pw AB9cdefg -group service,op_copy_services csadmin 

Date/Time: 16. Mõrz 2009 15:01:33 GMT-07:00 IBM DSCLI Version: 5.4.2.540 DS: - 

CMUC00133I mkuser: User csadmin successfully created. 

For the exact syntax of any DS CLI command, see the IBM System Storage DS8000: 

Command-Line Interface User’s Guide, SC26-7916. You can also use the DS CLI help 

command for further assistance. 

1.2 Directory Services and LDAP 

Until now, the local user management, as explained in 1.1, “DS8000 basic user management 

and access” on page 2, has been the only possibility with the DS8000 series. Maintaining 

local repositories of users and their permissions is simple and convenient when only dealing 

with a small number of users and a small number of DS8000 servers or other systems. 

However, as the number of users and interconnected systems grows, it quickly becomes 

difficult and time consuming to manage. 

DS8000 v4.2 can now exploit the possibilities offered by Directory Services and LDAP to 

simplify these management tasks. Directory Services typically provides a repository to store 

the location and other relevant information about resources, combined with an access method 

and related administration services. Common examples are a telephone directory and a 

library card catalog. For a telephone directory, the objects listed are individuals, businesses, 

and if applicable, the services they provide. Such information can be retrieved by name (white 

pages) or service categories (yellow pages). 

In computer terms, a directory is a specialized database, also called a data repository, that 

stores typed and ordered information about objects. Directories allow users or applications to 


find resources that have the characteristics needed for a particular task. A directory can also 

be used to store user IDs, passwords, and other credentials of system users. For example, 

the World Wide Web cannot function without a directory of available Web sites. This directory 

is what is referred to as a Domain Name Service or Domain Name System (DNS). The DNS 

allows users to search the Web for servers without any knowledge of the network address, 

host name, or IP address. 

A directory is often described as a database, but a specialized one that has characteristics 

that set it apart from general purpose relational databases. One special characteristic of 

directories is that they are accessed (read or searched) more often than they are updated 

(written). Hundreds of people might look up an individual’s phone number, or thousands of 

print clients might look up the characteristics of a particular printer, but the phone number or 

printer characteristics rarely change. 

Because the number of different networks and applications has grown, the number of 

specialized directories of information has also grown, resulting in islands of information that 

are difficult to share and manage. The ability to maintain and access all of this information in 

a consistent and controlled manner it might provide a focal point for integrating a distributed 

environment into a consistent and seamless system. 

The LDAP is an open industry standard that has evolved to meet these needs. LDAP defines 

a standard method for accessing and updating information in a directory. LDAP has gained 

wide acceptance as the directory access method of the Internet and is, therefore, becoming 

strategic within corporate intranets. 

LDAP defines a communication protocol. That is, it defines the transport and format of 

messages that are used by a client to access data in an X.500-like directory. LDAP does not 

define the directory service itself. When people talk about the LDAP directory, they are 

referring to the information that is stored and that can be retrieved by the LDAP protocol. 

All LDAP servers share many basic characteristics because they are based on the industry 

standard Request for Comments (RFCs). However, because of implementation differences, 

they are not all completely compatible with each other when a standard is not defined. For 

more information about RFCs, particularly regarding LDAP RFC 4510-4533, see the following 

Web address: 

http://www.ietf.org/rfc.html 

The implementation of directory service is based on a client/server relation. If an application 

expects some data from a object stored in a directory, the application must integrate with a 

client that connects to the directory server. The servers read the database and send the data 

back to the client application. 

For a more detailed description of LDAP, see the IBM Redbooks publication Understanding 

LDAP - Design and Implementation, SG24-4986. 

The following directory servers are the most common: 

► IBM Tivoli Directory Server 

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp 

For installation and configuration steps, see Appendix C, “Installing Tivoli Directory Server 

v6.2” on page 61. 

► IBM Lotus® Domino® 

http://www.ibm.com/software/lotus/products/domino/ 


► Microsoft Active Directory® 

http://www.microsoft.com/windowsserver2008/en/us/active-directory.aspx 

► openLDAP for Linux 

http://www.openldap.org/ 

For installation and configuration steps, see Appendix D, “Installing openLDAP in a SUSE 

Linux environment” on page 73. 

1.3 Overview of LDAP-based authentication for the DS8000 

Figure 1-4 shows an overview of the DS8000 LDAP-based authentication architecture. 

Browser 

Host System 

1 

LDAP Service 

TCP/IP 

1 

Remote desktop 

7 

Directly 

TPC 

host 

only 


Tivoli Storage Productivity Center 4.1 

6 

The authentication 

server provides the 

connection to the 

LDAP or other 

repositories. 

1 

TPC GUI 

DS GUI 

2 

TIP 


Server 

1,2,3 

DS CLI 

Client 

ESSNI 

Client 

Tivoli Storage Productivity 

Center GUI 

The authentication is now 

managed through the 

Authentication Server, a 

Tivoli Storage Productivity 

Center component, and a 

1,2,3 new authentication client at 

TCP/IP 

the HMC. 


ESSNI 

Server 

4 9 


Client 


ESSNI 

Server 


Client 

DS8000 

Complex 1 


Complex 2 

Figure 1-4 Communication between the DS8000 HMC, Tivoli Storage Productivity Center, LDAP and 

DS CLI or DS GUI client 

Communication between the DS8000 HMC and the various administrative clients (DS CLI, 

DS GUI) is unchanged compared to basic user authentication. The communication model still 

uses a client/server connection between the DS8000 HMC ESSNI server and the 

administrative client ESSNI client. 

The big difference with basic authentication is that the DS8000 user IDs (as used by the 

DS CLI or the DS GUI) are no longer locally managed and stored at the HMC. Instead they 

are managed and stored in an LDAP directory server. However, the HMC cannot directly 

communicate with the LDAP server. The HMC is configured to authenticate user IDs and 

passwords against a new service provided by Tivoli Storage Productivity Center v4.1, called 

the Authentication Server. This Authentication Server in Tivoli Storage Productivity Center 

receives authentication requests from an Authentication Client that is located at the HMC. 

5 

3 

8 

Chapter 1. LDAP authentication for DS8000 7 

10

The Authentication Client also acts as an LDAP client to communicate those requests to the 

LDAP servers. 

Note: Tivoli Storage Productivity Center users are also now managed by LDAP. 

The HMC can still support basic authentication. The authentication method (either basic or 

LDAP) that is used is determined by setting an authentication policy in the DS GUI user 

administration menu. By default, the HMC is not configured to use LDAP, then the 

Authentication Server, which resides at the HMC, is not used. The initial authentication policy 

is set to the basic method. The two methods (basic or LDAP) are mutually exclusive. 

To use LDAP authentication, the authentication type at the DS8000 must be changed to 

Storage Authentication Service (SAS). The SAS policy includes all the information that is 

required for the LDAP connection and authentication. This information includes the host name 

or the IP address of the Authentication Server. It also includes the location of the truststore 

file, which is a digitally signed certificate of the Authentication Server. The certificate is used 

to establish a Secure Sockets Layer (SSL) connection between the Authentication Server and 

the Authentication Clients. The communication between the LDAP server and Authentication 

Server can also be configured to use a secure connection through SSL, but it is not required. 

As stated previously, the Authentication Server is provided by the Tivoli Storage Productivity 

Center 4.1. Tivoli Storage Productivity Center 4.1 also includes the Tivoli Integrated Portal. 

Tivoli Integrated Portal is a browser-based utility that is used to administrate and manage the 

Authentication Server. When provided with the correct authority, Tivoli Integrated Portal can 

also be used to administrate LDAP user and groups through a web browser started on any 

host. 

For example, when using the DS CLI, the connection from a user standpoint is still 

established as it was without LDAP. The user establishes the connection by specifying the IP 

address of the HMC and is prompted for a user ID and password. Now, because the DS8000 

has an active SAS policy, the Authentication Client sends the user request to the 

Authentication Server. The Authentication Server validates the user’s credentials with LDAP. If 

valid, an authentication OK token is returned to the ESSNI server, which executes the 

command against the DS8000. In Figure 1-4 on page 7, this sequence is noted by the circled 

numbers. 

1.4 Benefits for DS8000 administrators and users 

When applications access a standard common directory that is designed in a proper way, 

rather than using application-specific directories, redundant and costly administration can be 

eliminated, and security risks are more controllable. With DS8000 basic authentication, user 

administration is isolated and must be separately maintained. Each DS8000 in your 

environment has its own local user repository. 

DS8000 authentication through LDAP offers the following benefits: 

► Centralized user management from one or more LDAP servers 

The user IDs and the role definition are stored and managed in one central location. 

► Integration with existing Directory Services 

If you already use a directory service, you can integrate DS8000 users and, if needed, 

create a separate DS8000 LDAP group. 


► More flexible user management 

You have different ways to add, change, or remove a user ID or to reset a password: 

– Directly with the LDAP server GUI 

– By using the Web (for example, Tivoli Directory Server Web Administration Tool) 

– User Management by using the Tivoli Integrated Portal of the Tivoli Storage 

Productivity Center 4.1 

– Use of the same user ID to access all DS8000 systems in the enterprise 

– Password policy management 

Tip: Use LDAP if it is already in use or if you have a large pool of DS8000 systems and 

other LDAP-enabled servers to administrate it. 

► Even though LDAP support can provide single sign-on (SSO) capability by using the same 

credentials to access multiple DS8000 servers, it remains possible to create separate user 

IDs for one person, while maintaining those user IDs by using LDAP. This is important if 

the same person needs to access multiple DS8000 servers with different authorization 

levels. Security isolation with multiple DS8000 systems remains possible with LDAP. 



Chapter 2. Implementing LDAP for the 


2 

In this chapter, we explain how to implement Lightweight Directory Access Protocol (LDAP) 

authentication for the IBM System Storage DS8000 server. The implementation involves the 

following high level tasks: 

1. Installing the LDAP servers 

2. Installing and configuring the Tivoli Storage Productivity Center servers 

3. Creating the certificates and the truststore file 

4. Configuring the DS8000 for LDAP authentication 


2.1 Test environment 

Figure 2-1 shows the layout of the test environment that we set up for writing this paper. As a 

best practice, set up an environment that ensures high availability by providing redundancy for 

the installation key elements. 

In our case, we used two LDAP servers, two Tivoli Storage Productivity Center servers, and 

two Hardware Management Consoles (HMCs) for the DS8000. As you can see in the 

diagram, the administration workstation (DS command line interface (CLI) or DS graphical 

user interface (GUI)) has redundant paths to the dual HMCs and Tivoli Storage Productivity 

Center servers. The second DS8000 server is for illustration purposes, but you can do the 

cabling and setup as illustrated when managing multiple DS8000 servers. 

The DS8000 R4.2 LDAP authentication feature enables the definition of a backup LDAP and 

a backup Tivoli Storage Productivity Center server. However, only one of each of the 

redundant servers can be active at a time. 

Figure 2-1 High available environment 

2.2 Installing the LDAP servers 

As described in Chapter 1, “LDAP authentication for DS8000” on page 1, the main benefit of 

an LDAP-based authentication is the centralized user management that it allows. Therefore, if 

you already have an operating LDAP server in your environment, use the same servers for 

DS8000 user authentication. 

If you do not have an LDAP server installed yet, use the Tivoli Directory Server. For detailed 

installation instructions, see Appendix C, “Installing Tivoli Directory Server v6.2” on page 61. 


Alternatively in a Linux environment, you can opt for an openLDAP server. For details, see 

D.1, “Installing the required LDAP packages” on page 74. 

As previously indicated, also provision a second (standby) LDAP server for redundancy. We 

refer to those LDAP servers in this paper as LDAP server1 and LDAP server2. 

2.3 Installing and configuring the Tivoli Storage Productivity 

Center servers 

IBM Tivoli Storage Productivity Center is storage infrastructure management software that 

can centralize, automate, and simplify the management of complex and heterogeneous 

storage environments. Tivoli Storage Productivity Center is included on the Storage System 

Productivity Center (SSPC) console that is recommended with DS8000 installation. 

Remember that Tivoli Storage Productivity Center or SSPC (which includes Tivoli Storage 

Productivity Center) is now required for DS8000 GUI access. Tivoli Storage Productivity 

Center v4.1 is required for LDAP authentication support. 

If you plan or must install a new Tivoli Storage Productivity Center server, see the installation 

instructions in Appendix A, “Installing Tivoli Storage Productivity Center 4.1 on Windows 

Server 2008” on page 39. 

As previously indicated, you must also provision a second (standby) Tivoli Storage 

Productivity Center server for redundancy. We refer to those Tivoli Storage Productivity 

Center servers as TPC server1 and TPC server2. 

If you already have Tivoli Storage Productivity Center 4.1 servers installed, but not configured 

for LDAP authentication, use the Tivoli Integrated Portal component of Tivoli Storage 

Productivity Center to configure them for LDAP. For more information, see Appendix B, 

“Configuring Tivoli Storage Productivity Center for DS8000 LDAP authentication” on page 51. 

After the Tivoli Storage Productivity Center servers are installed and configured for LDAP, 

proceed to the following section, 2.4, “Creating the certificates and the truststore file”. 

2.4 Creating the certificates and the truststore file 

The certificate and the truststore file from the Tivoli Storage Productivity Center server or 

servers are needed to secure Secure Sockets Layer (SSL) communication between the 

DS8000 HMC and the Tivoli Storage Productivity Center server. The certificate and truststore 

file are shared between the Tivoli Storage Productivity Center servers and HMCs. 

2.4.1 Creating the certificate and the truststore file on TPC server1 

The Tivoli Storage Productivity Center v4.1 server administration is done to a component 

called the Tivoli Integrated Portal. Tivoli Integrated Portal is packaged with Tivoli Storage 

Productivity Center. This component provides a GUI front end to the Tivoli Storage 

Productivity Center administration, accessible from a Web browser. 

The Tivoli Integrated Portal is part of Tivoli Storage Productivity Center 4.1 and is 

automatically installed as part of any Tivoli Storage Productivity Center 4.1 installation. 

Chapter 2. Implementing LDAP for the DS8000 13

To create the certificate and truststore file: 

1. Open a Web browser and point it to the Tivoli Integrated Portal, which is typically 

accessible from the following URL: 

https://IP-Address:16311/ibm/console 

The default Tivoli Integrated Portal installation secures the https transport with a self 

signed certificate. Depending on the browser that you use, you might receive an exception 

message and have to accept that certificate as a trusted certificate. 

2. Export the certificate: 

a. Log in to the Tivoli Integrated Portal console. 

b. Navigate to the SSL certificate and key management →Key stores and 

certificates →NodeDefaultKeyStore →Personal certificates →Extract certificate 

page (Figure 2-2). 

c. Under General Properties, enter the path and file name on the IBM Tivoli Integrated 

Portal server indicating where to extract the certificate. 

For example, if you enter the path and name c:\default_itso.cer, the 

default_itso.cert file is generated in the Tivoli Storage Productivity Center server C:\ 

root folder. The file name can be any file name that you provide. Data type defines the 

encoding scheme (for example, Base64 encoded ASCII data) for the SSL certificate. 

Click OK. 

Figure 2-2 Extract certificate page 

3. Create the truststore file: 

a. Launch the iKeyman utility that is included with Tivoli Storage Productivity Center 4.1. 

For example, in Windows 2003 Server, open a Command Line window and enter the 

following command to open the IBM Key Management window: 

c:\Program Files\IBM\tivoli\tip\bin\ikeyman.bat 

The iKeyman utility is a GUI-based tool that you can use to manage your digital 

certificates. With iKeyman, you can create a new key database or test a digital 

certificate, add certificate authority (CA) roots to your database, copy certificates from 

one database to another, request and receive a digital certificate from a CA, set default 

keys, and change passwords. 


Certificate authority: A certificate authority is a trusted central administrative 

entity that can issue digital certificates to users and servers. The trust in the CA is 

the foundation of trust in the certificate as a valid credential. A CA uses its private 

key to create a digital signature on the certificate that it issues to validate the 

certificate's origin. Others can use the CA certificate’s public key to verify the 

authenticity of the certificates that the CA issues and signs. The term truststore 

refers to a special designation that is given to a CA certificate. This truststore 

designation allows a browser or other application to authenticate and accept 

certificates that the CA issues. 

b. In the IBM Key Management window (Figure 2-3), click Key Database File → New. 

Figure 2-3 iKeyman utility 


c. In the New panel (Figure 2-4): 

i. For Key database type, select a type or leave the default of JKS. 

ii. For File Name, enter a file name. For example, enter itso_trust_store.jks. 

Note: For Microsoft Windows systems, the default location for the generated key 

file is c:\Program Files\IBM\tivoli\tip\bin\. 

iii. Click OK. 

Figure 2-4 Selecting an export location and setting the file name 

iv. In the Password Prompt window (Figure 2-5), specify a password that you can 

remember for the truststore file. Click OK. 

Figure 2-5 Specifying a password 

After the truststore file is created, you return to the IBM Key Management window. 


4. Import the certificate into the truststore file: 

a. Add the exported certificate file from the Tivoli Integrated Portal (see Figure 2-2 on 

page 14) to the truststore file: 

i. From the IBM Key Management window (Figure 2-6), click Add. 

Figure 2-6 Adding a certificate to a truststore file 

ii. In the Add CA certificate from a file window (Figure 2-7), click Browse. 

iii. Select the certificate file that you created in step 2 on page 14 (see Figure 2-2) and 

click OK. 

Figure 2-7 Selecting the certificate authority 


iv. In the Enter a Label window (Figure 2-8), enter any label (any character string of 

your choice). For example, we enter itso_cert_label. Then click OK. 

Figure 2-8 Specifying a key label 

The certificate is successfully stored in the truststore file, as shown in Figure 2-9. 

Figure 2-9 CA successfully stored in the truststore file 

b. Exit the iKeyman tool and locate the truststore file. In our example, the file is in 

c:\Program Files\IBM\tivoli\tip\bin\itso_trust_store.jks. 

You need this truststore file and password while configuring the LDAP-based policy on 

the DS8000 server. 

2.4.2 Setting up TPC server2 

As previously discussed, as a best practice, install and configure a second Tivoli Storage 

Productivity Center server (TPC server2) to guarantee access to the DS8000 in case of a 

failure of TPC server1. Only one Tivoli Storage Productivity Center server can be active for 

LDAP authentication. TPC server2 is typically in standby and takes over in case of a failure at 


TPC server1. Implement TPC server2 preferably on the same hardware configuration as TPC 

server1, but imperatively with the same LDAP server/branch information as TPC server1. 

To do a basic Tivoli Storage Productivity Center installation, see the instructions in 

Appendix A, “Installing Tivoli Storage Productivity Center 4.1 on Windows Server 2008” on 

page 39. The additional setup tasks described in this section are required. 

Note: The Tivoli Storage Productivity Center servers and Tivoli Integrated Portal are 

implemented as IBM WebSphere® application servers, which can securely communicate 

by using the Lightweight Third Party Authentication (LTPA) protocol. 

LTPA is intended for distributed, multiple application server and machine environments. The 

LTPA protocol enables WebSphere Application Server to provide security in a distributed 

environment by using cryptography. Application servers distributed in multiple nodes can 

securely communicate by using this protocol. 

It also provides a single sign-on (SSO) feature where a user is required to authenticate only 

once. The LTPA protocol uses cryptographic keys to encrypt and decrypt user data that 

passes between the servers. These keys must be shared between the different servers, 

assuming that all the servers involved use the same LDAP or custom registry. The default 

LTPA keys are automatically generated during the installation process. 

All of the Tivoli Storage Productivity Center Server processes (Tivoli Integrated Portal, node, 

WebSphere Application Server) share the same set of keys. If key sharing is required 

between different servers, export them from one server and import them to the other server. 

For security purposes, the exported keys are encrypted with a user-defined password. This 

same password is needed when importing the keys into another server. 

Exporting and importing the LTPA keys 

On TPC server2, export and import the LTPA keys by using either the CLI or the Tivoli 

Storage Productivity Center GUI. 

Using the CLI to export and import the LTPA keys 

To use the CLI to export and import the LTPA keys: 

1. Export the LTPA keys that were initially created when installing TPC server1: 

a. On TPC server2, open a command window and go to the /bin folder. 

b. Enter the wsadmin command as follows to export LTPA keys from TPC server1 to a file 

on TPC server2: 

wsadmin -user -password -lang jython 

-port -host -f "/tip/scripts/exportLTPAKeys.py" "" 

 

Note the following explanation: 

-user is the user name from the Tivoli Integrated Portal administrator. 

-password is the password from the Tivoli Integrated Portal administrator. 

-lang jython is the scripting language used for the export script (-f). 

-port is the port on which the Tivoli Integrated Portal is listening. The default is port 

16311. 

-host is the host name or IP address the Tivoli Integrated Portal server. 


-f is the export script path in the local Tivoli Storage Productivity Center server 

installation directory/tip/scripts directory. The script name is 

exportLTPAkeys.py. 

LTPA keys file name is the name (or path and filename) of the exported LTPA file. 

ltpaKeysPassword is the password that is used to encrypt and decrypt the LTPA 

keys. During import, this password must match the password that is used to export 

the keys at another LTPA server (for example, another application server, and so 

on). During export, remember this password so that you can enter it during import. 

Example 2-1 illustrates the command that we used (in our test environment) to export 

the keys. The exportedLTPAkeyfile file, which contains the LTPA keys of TPC server1 

and that we import to TPC server2, is generated. 

Note: Use forward slashes when specifyng the path names for files. 

Example 2-1 Exporting the key 

C:\Program Files\IBM\Tivoli\TIP\bin>wsadmin -user tpcadmin2 -password super321 -lang 

jython -port 16313 -host 9.11.112.112 -f "c:/program 

files/ibm/tpc/tip/scripts/exportLTPAKeys.py" "c:/share/exportedLTPAkeyfile" passw0rd 

2. Import the LTPA key: 

a. In the same command window on TPC server2, enter the following wsadmin command 

to import the LTPA keys in Tivoli Integrated Portal and then into the device server. The 

parameters have the same meaning as explained in step 1 on page 19. 

wsadmin -user -password -lang jython -f 

"/tip/scripts/importLTPAKeys.py" "" 

The device server discovers storage subsystems and SAN fabrics. Then it gathers 

information about storage subsystems and SAN fabrics and analyzes their 

performance. The device server controls the communication with agents and the data 

collection from agents that scan storage area network (SAN) fabrics. It is also 

responsible for the creation and monitoring of replication relationships between storage 

devices. 

Example 2-2 shows the key being imported to the device server. 

Example 2-2 Importing the key to the device server 

C:\Program Files\IBM\Tivoli\TIP\bin>wsadmin -user tpcadmin2 -password passw0rd -lang 

jython -f "c:/program files/ibm/tpc/tip/scripts/importLTPAKeys.py " 

c:/share/exportedLTPAkeyfile" passw0rd 

b. Change the directory to the device server’s TIP\bin folder and run the same command 

as shown in Example 2-3. 

Note: Use forward slashes when specifyng the path names for files. 

Example 2-3 Importing the key to the TIP folder 

C:\Program Files\IBM\TPC\device\apps\was\bin>wsadmin -user tpcadmin2 -password 

passw0rd -lang jython -f "c:/program files/ibm/tpc/tip/scripts/importLTPAKeys.py " 

c:/share/exportedLTPAkeyfile" passw0rd 


Using the GUI to export and import the LTPA keys 

To use the Tivoli Storage Productivity Center GUI to export and import the LTPA keys: 

1. Export the LTPA key: 

a. To access the Tivoli Storage Productivity Center administrative console (Tivoli 

Integrated Portal), type the following URL in a Web browser: 

http://server_name:port_number/ibm/console 

b. In the left pane, select Security → Secure administration, applications, and 

infrastructure → Authentication mechanisms and expiration. 

c. In the window that opens (Figure 2-10): 

i. Under Cross-cell single sign-on, in the Password and Confirm password fields, 

enter the password to encrypt the LTPA keys. Remember the password so that you 

can use it later when the keys are imported into the other server. 

ii. In the Fully qualified key file name field, specify the fully qualified path to the 

location where you want the exported LTPA keys to reside. You must have write 

permission to this file. 

iii. Click Export keys to export the keys to the location that you specified in the Fully 

qualified key file name field. 

iv. Click OK to confirm the changes and click Save to save your configuration. 

Figure 2-10 Exporting the LTPA key 


2. Import the LTPA key: 

a. Access the Tivoli Integrated Portal administrative console for the server that will receive 

the imported keys by typing the following URL in a Web browser: 

http://server_name:port_number/ibm/console 

b. In the left pane, click Security → Secure administration, applications, and 

infrastructure → Authentication mechanisms and expiration. 

c. In the window that opens: 

i. Under Cross-cell single sign-on, in the Password and Confirm password fields, 

enter the password that is used to decrypt the LTPA keys. This password must 

match the password that was used at the server from which you are importing the 

keys. 

ii. In the Fully qualified key file name field, specify the fully qualified path to the 

location where the signer keys reside. You must have write permission to this file. 

iii. Click Import keys to import the keys to the location that you specified in the Fully 

qualified key file name field. 

iv. Click OK and Save to save the changes to the master configuration. It is important 

to save the new set of keys to match the new password so that no problems are 

encountered when starting the servers later. 

The LTPA keys in TPC server1 and TPC server2 are now in sync. 

2.4.3 Copying the truststore file from TPC server1 to TPC server2 

For TPC server2 to take over in case a TPC server1 failure, both servers must have access to 

identical truststore files. Copy the truststore file that was created for TPC server1 (see 2.4.1, 

“Creating the certificate and the truststore file on TPC server1” on page 13) to TPC server2. 

2.5 Configuring the DS8000 for LDAP authentication 

The DS8000 must be configured to use LDAP authentication. To perform the configuration, 

you can use either the DS GUI or the DS CLI. 

Important: You must have redundant LDAP servers. If the LDAP service is not available, 

you cannot log on to a DS8000 system that is enabled for LDAP to perform administrative 

tasks. 

Configuring DS8000 LDAP authentication by using the GUI 

To configure DS8000 LDAP authentication by using the GUI: 

1. Open the DS8000 GUI using the administrative user ID and password. Enter the User 

Name and Password. Click OK. 

2. On the DS8000 Storage Manager Menu (left pane), select User Administration. 

3. In the User and Authentication Policy Administration Summary page, select a Complex 

Name. 


4. Click Select action and select Create Storage Authentication Service Policy 

(Figure 2-11). 

Figure 2-11 Select Create Storage Authentication Service Policy 

5. On the Authentication Service Configuration page (Figure 2-12 on page 24): 

a. For Policy Name, enter any name. You can define more than one policy, but only one 

can be active. You can also switch freely between the different policies. 

b. For Authentication Service URL (Primary), enter the URL to the Tivoli Integrated Portal 

(on TPC server1). The following URL is the default to the truststore: 

https://tip_server_host:16311/TokenService/services/Trust 

c. For Authentication Service URL (secondary), enter the backup URL that points to TPC 

server2. 

d. For Authentication Service Client User ID, enter the user ID from the Tivoli Integrated 

Portal that is set up by installation. 

e. For Authentication Service Client Password, enter the password from the Tivoli 

Integrated Portal user. 

f. For Confirm Authentication Service Client Password, enter the password again. 

g. Click Next. 

Port number: The port for ESS service (16311) is 1 plus the default Tivoli Integrated 

Portal port 16310. If you change the default Tivoli Integrated Portal port, during 

installation to, say 17522, then the port# to use for ESS service is 17523 (one plus that 

Tivoli Integrated Portal port number). 

The ESS/Authentication Service URL is as follows: 

https://yourserver.com:17523/TokenService/services/Trust 


Figure 2-12 Authentication Service Configuration 

6. On the Truststore file Information page (Figure 2-13): 

a. For Truststore File Location, see 2.4, “Creating the certificates and the truststore file” 

on page 13. 

b. For Truststore File Password, enter the password that when the truststore was created. 

c. For Confirm Truststore File Password, enter the password. 

d. Click Next. 

Figure 2-13 Truststore file Information page 


7. On the Map External Users and User Groups to DS8000 User Roles page (Figure 2-14): 

a. Enter the External Entity Name. Enter the name of the user or user group that exists in 

the LDAP directory. 

b. Select the external Entity Type. The type of entity can be External User Group or 

External User Name. 

c. For DS8000 User Role, select a role from the list (see Table 3-1 on page 34). 

d. Click the Add button. 

e. To map more than one user or group, repeat these steps. For detailed information 

about user groups and roles, see 3.3, “User administration for Tivoli Storage 

Productivity Center servers” on page 36. 

f. Click Next. 

Figure 2-14 Map External Users and User Groups to DS8000 User Roles window 


8. On the Verification page (Figure 2-15), on which you can see the settings that will be 

stored, verify the information and click Next to continue or click Back to make changes. 

Figure 2-15 Verification page 

9. On the Summary page (Figure 2-16), leave the Activate the Policy check box cleared. 

Click Finish to create the policy. Note that in the next step, we test the policy before 

activating it. 

Figure 2-16 Summary page 


10.On the Manage Authorization Policy page (Figure 2-17), select a policy. Under the Select 

action menu, click Test Authentication Policy. 

Figure 2-17 Test Authentication Policy 

11.In the Test Storage Authentication Service Policy window (Figure 2-18), enter values for 

the External User Name and External User Password input fields. The user must be an 

existing user from the LDAP Directory and mapped to a local DS8000 role. Then click OK. 

Figure 2-18 Test policy 


The test takes a few seconds to complete. When complete, the Test summary page is 

displayed. If the test was successful, the Result State box is green and the Result details 

cell is empty, as shown in Figure 2-19. If something is wrong, the Result Status cell is red 

and the error messages is displayed in the Result details box. In this case, go back to the 

configuration and check the settings. 

Figure 2-19 Test completes successfully 

12.Activate the configuration. Select a policy. Under the Select action menu, click Activate. 


13.In the Activate Storage Authentication Service Policy window (Figure 2-20): 

a. For External User Name, enter a name that exists and is valid user name from the 

LDAP Directory. 

b. Enter the External User password. 

c. Click OK to activate the policy. 

Figure 2-20 Activate the configuration 

Configuring DS8000 LDAP authentication by using the DS CLI 

In addition to using the GUI, you can configure the DS8000 external authentication policy 

through the command line interface (CLI). To configure with DS CLI: 

1. Go to the DS CLI Install Directory and open the DCSCLI command window. 

2. In the DS CLI command window, enter the HMC IP Address, User Name, and Password. 

3. To see the existing Authentication policies, enter the lsauthpol command as shown in 

Example 2-4. As you can see, the default initialPolicy is set for basic (non-LDAP) 

authentication. 

Example 2-4 Listing Authentication policies 

dscli> lsauthpol 

Date/Time: March 11, 2009 9:17:16 AM MST IBM DSCLI Version: 5.4.2.540 DS: - 

name type state 

========================== 

initialPolicy Basic active 


4. Create a new empty policy, where the -type sas specifies the authentication policy type 

by entering the mkauthpol -type sas itsopolicy command as shown in Example 2-5. 

Currently, SAS (Storage Authentication Service) is the only valid value for this parameter 

and it is required. itsopolicy defines the name from the new policy. 

Example 2-5 Creating a new policy 

dscli> mkauthpol -type sas itsopolicy 


CMUC00365I mkauthpol: The authentication policy itsopolicy has been created. 

5. Add a policy server or policy servers to the policy as shown in Example 2-6 by entering the 

the setauthpol command with the -action setauthserver and -loc parameters, where 

the -loc parameter is the URL to the TPC server1-. 

Example 2-6 Setting the policy server 

dscli> setauthpol -action setauthserver -loc 

https://9.11.240.201:16311//TokenService/services/Trust itsopolicy 


CMUC00366I setauthpol: The authentication policy itsopolicy has been modified. 

6. Add the keystore file to the policy. Enter the setauthpol command with the -action 

settruststore parameter and the -loc parameter, where the value is the location of the 

truststore file (see 2.4, “Creating the certificates and the truststore file” on page 13), and 

-pw parameter for the truststore file password. See Example 2-7. 

Example 2-7 Setting the key 

dscli> setauthpol -action settruststore -loc c:\key_itso.jks -pw passw0rd 

itsopolicy 



7. Add the ESS user to the policy by entering the setauthpol command with -action 

setsasuser parameter, as shown in Example 2-8. For more details about the ESS user 

see Appendix A, “Installing Tivoli Storage Productivity Center 4.1 on Windows Server 

2008” on page 39. 

Example 2-8 Setting the ESS user 

dscli> setauthpol -action setsasuser -username tipadmin -pw passw0rd 

itsopolicy 



8. Map existing users and user groups from the LDAP server to user groups on the DS8000 

by entering the setauthpol command with -action setmap parameter and -groupmap 

User:Group values, as shown in Example 2-9. 

Example 2-9 Mapping a user to a group 

dscli> setauthpol -action setmap -groupmap admin:Administrators itsipolicy 


CMUC00366I setauthpol:Authentication policy itsopolicy successfully modified. 


9. Now that the policy is set up, check it as shown in Example 2-10. The policy is now in 

inactive state. 

Example 2-10 Listing of the available policiies 

dscli> lsauthpol itsopolicy 



========================= 

itsopolicy SAS inactive 

10.To view the configuration parameters, enter the showauthpol command, as shown in 

Example 2-11. 

Example 2-11 Showing the configuration parameters 

dscli> showauthpol itsopolicy 


name itsopolicy 

type SAS 

state inactive 

location https://9.11.240.201:16311//TokenService/services/Trust 

truststore itsopolicy_trustStore.jks 

sasuser tipadmin 

11.Test the configuration by entering the testauthpol command as shown in Example 2-12. 

Example 2-12 Testing the configuration 

dscli> testauthpol -username tipadmin -pw passw0rd itsopolicy 


CMUC00366I testauthpol:Authentication policy itsopolicy successfully verified. 

12.If the test completed successfully, active the policy by entering the chauthpol command 

with the -activate parameter as shown in Example 2-13. 

Example 2-13 Activating the policy 

dscli> chauthpol -quiet -activate -username tipadmin -pw passw0rd itsopolicy 



13.Check the state for the policy by entering the lsauthpol command (Example 2-14). 

Example 2-14 Listing the policy 

dscli> lsauthpol itsopolicy 



============================ 

itsopolicy SAS active 



Chapter 3. User, group, and role 

administration 

3 

In this chapter, we explain how to map IBM System Storage DS8000 users and roles with 

Lightweight Directory Access Protocol (LDAP) users and groups. We also explain the 

mapping of Tivoli Storage Productivity Center users with LDAP users and groups. 

The chapter includes the following topics: 

► 3.1, “DS8000 to LDAP groups mappings using the DS GUI” on page 34 

► 3.2, “DS8000 to LDAP groups mappings using the DS CLI” on page 35 

► 3.3, “User administration for Tivoli Storage Productivity Center servers” on page 36 


3.1 DS8000 to LDAP groups mappings using the DS GUI 

LDAP groups (for example, groups in your LDAP repository) are associated with predefined 

roles. When a user ID is authenticated to a DS8000 through the graphical user interface (GUI) 

or command line interface (CLI), the user’s membership in a particular LDAP group 

determines the user’s authorization level. Table 3-1 shows the association between DS8000 

user roles and authorization levels. 

Table 3-1 DS8000 roles and authorization levels 

Role Authorization level 

Administrator This user role has the highest level of authority. It allows a user to add or 

remove user accounts. This role has access to all service functions and 

DS8000 resources. 

Logical operator This role has access to resources that relate to logical volumes, hosts, host 

ports, logical subsystems, and volume groups, excluding security functions. 

Monitor This role has access to all read-only, nonsecurity service functions and all 

DS8000 resources. 

Physical operator This user role allows access to resources that are related to physical 

configuration, including storage complex, storage unit, storage image, 

management console, arrays, ranks, and extent pools. The physical operator 

role does not have access to security functions. 

Copy Services 

operator 

Logical operator and 

Copy Services 

operator 

To define the mappings: 

1. From the DS8000 User administration menu, select a storage complex. From the Select 

action list, select Manage Authentication Policy. Select a Storage Authentication Service 

policy, and from the Select action list, select Properties. 

2. In the Storage Authentication Service Policy Properties window (Figure 3-3 on page 38), 

click the External Users tab and complete the following actions: 

a. For External Entity Name, enter the name of the user or user group that exists in the 

LDAP Directory. 

b. For External Entity Type, select the type of entity, which can be External User Group or 

External User Name. 

c. For DS8000 User Role, select a role from the list. Refer to Table 3-1. 

d. Click Add. 

e. After you add external (LDAP) users or groups, click OK to apply the changes. If you 

want to discard the changes, click Cancel. 

34 IBM System Storage DS8000: LDAP Authentication 

This role has access to all Copy Services service functions and resources, 

excluding security functions. 

This role provides the authority of both the logical operator and Copy Services 

operator. 

No access This is the default selection. It must be the only assigned role. This role has 

no access to any service functions or DS8000 resources. This user role is 

assigned to a user account that is not associated with any other user role.

Figure 3-1 Storage Authentication Service Policy Properties window 

3.2 DS8000 to LDAP groups mappings using the DS CLI 

To map LDAP groups-or-users-to DS8000-group, use the setauthpol command. With the 

setauthpol command, you can modify, delete, or add a mapping. To add a new group map, 

use the -action setmap, -groupmap admin:Administrator command as shown in 

Example 3-1. In this command, admin is the DS8000 role group, and Administrator is the 

user group or user name from the LDAP repository. 

Example 3-1 Mapping groups to a DS8000 role 

dscli> setauthpol -action setmap -groupmap admin:Administrators itsipolicy 



The DS8000 authority group roles for the DS CLI (see Table 3-1 on page 34) have the 

following possible values: 

► admin 

► op_storage 

► op_volume 

► op_copy_services 

► service 

► monitor 

► no_access 

Chapter 3. User, group, and role administration 35

To add a new user map, use the -action setmap, -userpmap admin:Administrator command. 

In this command, admin is the DS8000 role group, and Administrator is the user from the 

LDAP repository. The group roles are the same as described in Table 3-1 on page 34. 

3.3 User administration for Tivoli Storage Productivity Center 

servers 

Access to the Tivoli Storage Productivity Center servers can now also be controlled and 

managed by using LDAP. 

3.3.1 Tivoli Storage Productivity Center roles to LDAP group mappings 

After installing IBM Tivoli Storage Productivity Center, you must assign roles to individuals 

who will use Tivoli Storage Productivity Center. From the Role-to-Group Mapping node, you 

can map Tivoli Storage Productivity Center roles, such as Tape Operator or Fabric 

Administrator, to user groups that you create either in the operating system or in an 

LDAP-compliant repository. In this paper, we discuss only the mapping to LDAP. 

Tivoli Storage Productivity Center role-based authorization 

LDAP groups (for example, groups in your LDAP repository) are associated with predefined 

roles. When a user ID is authenticated to IBM Tivoli Storage Productivity Center through the 

GUI, CLI, or application programming interfaces (APIs), the user’s membership in a specific 

LDAP group is used to determine the user’s authorization level. 

Table 3-2 shows the association between Tivoli Storage Productivity Center user roles and 

authorization levels. 

Table 3-2 Roles and authorization levels in Tivoli Storage Productivity Center 

Role Authorization level 

Superuser Has full access to all Tivoli Storage Productivity Center functions. 

Productivity Center 

administrator 


Has full access to operations in the Administration section of the GUI 

Disk administrator Has full access to Tivoli Storage Productivity Center disk functions. 

Disk operator Has access to reports only for Tivoli Storage Productivity Center disk functions. 

This includes reports on tape devices. 

Fabric administrator Has full access to Tivoli Storage Productivity Center for Fabric functions. 

Fabric operator Has access to reports only for Tivoli Storage Productivity Center for Fabric 

functions. 

Data administrator Has full access to Tivoli Storage Productivity Center for Data functions. 

Data operator Has access to reports only Tivoli Storage Productivity Center for Data 

functions. 

Tape administrator Has full access to Tivoli Storage Productivity Center tape functions 

Tape operator Has access to reports only for tape functions.

If you select operating system authentication for your IBM Tivoli Storage Productivity Center, 

you do not have to create any of the groups before installation. The Tivoli Storage Productivity 

Center Superuser role is automatically mapped to the Administrators group on Windows, to 

the system group on AIX, or to the root group on Linux. 

Note: For more information about IBM Tivoli Storage Productivity Center user and group 

mapping, see the “User roles” topic in the Tivoli Storage Productivity Center Information 

Center at the following address: 

http://publib.boulder.ibm.com/infocenter/tivihelp/v4r1/index.jsp?topic=/com.ibm 

.tpc_V33.doc/fqz0_c_user_roles.html 

Establishing group mapping in Tivoli Storage Productivity Center 

To establish group mapping: 

1. Log in to the Tivoli Storage Productivity Center (Tivoli Integrated Portal) with your 

administrator user name and password. 

2. From the left Navigation Tree (Figure 3-2), expand Administrative Services → 

Configuration and select Role-toGroup Mappings. 

3. In the Role-to-Group Mappings pane: 

a. Choose a role to map and click Edit. 

Figure 3-2 Role-to-Group Mappings panel 

Chapter 3. User, group, and role administration 37

. In the Edit Group dialog box (Figure 3-3), enter the LDAP group (it must exist) that you 

want to map this role and click OK. 

Figure 3-3 Add group to Role window 

c. Select File → Save to store the changes. 


Appendix A. Installing Tivoli Storage 

Productivity Center 4.1 on 

Windows Server 2008 

A 

In this appendix, we explain how to install the Tivoli Storage Productivity Center 4.1. In the 

same procedure, we also install Tivoli Storage Productivity Center for Replication, the Tivoli 

Integrated Portal, and a DB2® database. In this installation, we use the most common default 

values, which are suitable for a majority of environments. 

Prerequisites: To install a Tivoli Storage Productivity Center server on Windows Server® 

2008, you must have the latest Windows Service Packs and Microsoft hot fixes installed. 

You must also first install the DB2 Server v9 for Windows. 


1. Before you launch the Tivoli Storage Productivity Center installation, in Windows Services, 

ensure that the DB2 services are started as indicated in the Status column in Figure A-1. 

This status is required because a DB2 database is installed in silent mode as part of the 

Tivoli Storage Productivity Center installation. 

Figure A-1 Windows Service Menu 

2. Launch the Tivoli Storage Productivity Center 4.1 installer. 

3. When prompted to select a language for the installation (Figure A-2), select your 

language. This setting is just the language for the installation wizard. You are prompted to 

select the language for Tivoli Storage Productivity Center later. Click OK. 

Figure A-2 Language selection 

4. In the License Agreement window, accept the terms of the license agreement to continue 

with the installation and click Next. 


5. For the type of Installation (Figure A-3): 

a. Select Typical installation. 

b. Clear the Agents and the Register with the agent manager check boxes. 

c. Specify a directory for the Tivoli Storage Productivity Center installation or use the 

default C:\Program Files\IBM\TPC directory. 

d. Click Next. 

Figure A-3 Tivoli Storage Productivity Center Server - Installation type 

Appendix A. Installing Tivoli Storage Productivity Center 4.1 on Windows Server 2008 41

6. In the next window (Figure A-4), specify the DB2 administrator ID and password. The 

default user ID is DB2admin. 

DB2 user ID: You must create the DB2 user ID first in Windows user management and 

have administrator and DB2 permissions. 

In the lower part of the window, specify the server name, server port, and agent port if 

applicable. Click Next to continue. 

Figure A-4 Tivoli Storage Productivity Center DB2 user and server IP port settings 


7. In the next window (Figure A-5), specify the Tivoli Storage Productivity Center 

administrator user ID and password. Again, the user ID should have operating system and 

database administrator authority. 

In the lower half of the window, enter the name of the Tivoli Storage Productivity Center 

server and the server port that will be used to communicate with the Tivoli Storage 

Productivity Center server. Click Next. 

Figure A-5 IP settings 


8. As shown in (Figure A-6), select the authentication method to use for Tivoli Storage 

Productivity Center. Select LDAP/Active Directory. Click Next. 

Figure A-6 Selecting the authentication method 

9. Define the basic LDAP connection settings (Figure A-7). Enter the LDAP server IP 

address and port number. If anonymous login’s are allowed by the LDAP server, the user 

and password are optional. Otherwise, select an LDAP user with the administrator role. 

Click Next. 

Figure A-7 LDAP connection settings 


10.Specify appropriate values to reflect the structure of your LDAP directory (Figure A-8). 

Click Next. 

Figure A-8 LDAP user and group attributes 

11.Specify the LDAP user who will have administrator privileges for Tivoli Storage 

Productivity Center (Figure A-9). Click Next. 

Figure A-9 Administrator user for Tivoli Storage Productivity Center 


12.Review the summary information (Figure A-10). If you are satisfied with the values and 

features that you chose, click Install to start the installation process. Otherwise click Back 

to change any of the installation values. 

Figure A-10 Summary information 

The Tivoli Storage Productivity Center installation process is now effectively taking place. 

13.In the Tivoli Storage Productivity Center for Replication installation window (Figure A-11), 

which opens when nearly ninety percent of the installation is completed, click Next. In 

doing so, you proceed with the Tivoli Storage Productivity Center for Replication 

installation wizard for the Tivoli Storage Productivity Center installation to complete. 

Figure A-11 Installation of Tivoli Storage Productivity Center for Replication 


14.In the system prerequisite check window (Figure A-12), click Next. 

Figure A-12 System check 

15.Accept the License Agreement for the Tivoli Storage Productivity Center for Replication to 

continue the installation process (Figure A-13). Click Next. 

Figure A-13 License agreement 


16.In the next window (Figure A-14), specify the program installation directory or accept the 

default. Click Next. 

Figure A-14 Installation directory 

17.Specify the Tivoli Storage Productivity Center for Replication administrator user name and 

password (Figure A-15). Click Next. 

Figure A-15 Tivoli Storage Productivity Center for Replication - Administrator details 


18.As shown in Figure A-16, select the Port for the WebSphere Application Server that Tivoli 

Storage Productivity Center for Replication uses for its runtime environment. The 

WebSphere Application Server is automatically installed. Click Next. 

Figure A-16 Port settings for WebSphere Application Server 

19.In the installation summary window (Figure A-17), review the details. If you are satisfied 

with the values, click Install to start the Tivoli Storage Productivity Center for Replication 

Installation Process. Otherwise, click Back to change any of the installation values. 

Figure A-17 Tivoli Storage Productivity Center for Replication - Installation summary window 


20.After the Tivoli Storage Productivity Center for Replication installation is complete, in the 

summary information window (Figure A-18), click Finish to return to the Tivoli Storage 

Productivity Center Install Process. 

Figure A-18 Tivoli Storage Productivity Center for Replication - Installation complete 

The Tivoli Storage Productivity Center installation resumes. 

21.In the summary window (Figure A-19) that indicates successful installation of Tivoli 

Storage Productivity Center, click Finish. 

Figure A-19 Tivoli Storage Productivity Center - Installation finished 

You can now further configure your Tivoli Storage Productivity Center server as explained in 

2.4, “Creating the certificates and the truststore file” on page 13. 


B 

Appendix B. Configuring Tivoli Storage 

Productivity Center for DS8000 

LDAP authentication 

If you already have Tivoli Storage Productivity Center 4.1 servers installed, but not configured 

for Lightweight Directory Access Protocol (LDAP) authentication, you must enable them for 

LDAP. To enable the servers for LDAP, you use Tivoli Integrated Portal before you configure 

the DS8000 itself for LDAP authentication. In this appendix, we explain how to enable LDAP 

on a Tivoli Storage Productivity Center 4.1 server. 

To configure Tivoli Storage Productivity Center for DS8000 LDAP support, begin by logging in 

to Tivoli Integrated Portal. Then proceed as explained in this chapter. 

Important: This configuration is only required when you want to enable LDAP support on 

an already installed Tivoli Storage Productivity Center server. Otherwise, LDAP support 

can be configured when you initially install a Tivoli Storage Productivity Center 4.1 server 

as explained in Appendix A, “Installing Tivoli Storage Productivity Center 4.1 on Windows 

Server 2008” on page 39. 


B.1 Securing the administration, applications, and 

infrastructure settings 

To secure the administration, applications, and infrastructure settings: 

1. From the Tivoli Integrated Portal console main widow, select Security → Secure 

administration, applications, and infrastructure. 

2. On the administrative console page (Figure B-1 on page 53), configure administrative, 

application, and infrastructure security on a global level. 

a. Select Enable administrative security. 

By selecting this option, you enable administrative security for this application server 

domain. Administrative security requires users to authenticate before obtaining 

administrative control of the application server. When enabling security, set the 

authentication mechanism configuration, and specify a valid user ID and password (or 

a valid administrator ID when the internalServerID feature is used) in the selected 

registry configuration. 

Note: There is a difference between the user ID (normally called the administrator 

ID), which identifies administrators who manage the environment, and a server ID, 

which is used for server-to-server communication. You do not need to enter a server 

ID and password when you are using the internal server ID feature. However, 

optionally, you can specify a server ID and password. To specify the server ID and 

password: 

1. Click Security → Global security. 

2. Under User accounts repository, select the repository and click Configure. 

3. In the Server user identity section, specify the server ID and password. 

b. Select Enable application security. 

Administrative security alone does not provide full security. In most environments, you 

must also enable application and resource security by selecting Enable application 

security. 

c. Under User account repository, from the Available realm definitions field, select 

Federated repositories to use LDAP as your account repository. Then click 

Configure to open the General Properties page (Figure B-2). 


Figure B-1 Administrative console page 

B.2 Configuring federated repositories 

Use the General Properties page (Figure B-2) to manage the realm of your federated security 

repositories. The realm can consist of identities in the file-based repository that is built into the 

system, in one or more external repositories (LDAP), or in both the built-in, file-based 

repository, and one or more external repositories. 

To configure the federated repositories: 

1. For Realm name, specify a name of your choice for the realm, for example, TIPRealm. You 

can change the realm name afterwards. 

2. For Primary administrative user name, type the name of the user with administrative 

privileges that is defined in the repository, for example, superAdmin. 

3. Under Server user identity, select the Automatically generated server identity check 

box to enable the application server to generate the server identity that is used for internal 

process communication. You can change this server identity on the Authentication 

mechanisms and expiration panel. 

4. Configure one or more Lightweight Directory Access Protocol (LDAP) repositories to store 

identities in the realm by using either of the following options as appropriate: 

– Click Add base entry to Realm to specify a repository configuration and a base entry 

into the realm. You can configure multiple different base entries in the same repository. 

– Click Remove to remove selected repositories from the realm. Repository 

configurations and contents are not destroyed. 

Appendix B. Configuring Tivoli Storage Productivity Center for DS8000 LDAP authentication 53

The following restrictions apply: 

The realm must always contain at least one base entry. Therefore, you cannot 

remove all entries. 

If you plan to remove the built-in, file-based repository from the administrative 

realm, verify that at least one user in another member repository is a console user 

with administrative rights. Otherwise, you must disable security to regain access to 

the administrative console. 

Figure B-2 General Properties page 

B.3 Adding a base entry to a realm 

When you click Add base entry to realm (Figure B-2), the page shown in Figure B-3 on 

page 55 is displayed. Use this page to configure secure access to an LDAP repository with 

optional failover servers. 

To view the administrative console page: 

1. Click Add Repository to specify a new external repository or select an external repository 

that is preconfigured. 


Figure B-3 Adding a repository to the realm 

2. On the Repository configuration page (Figure B-4 on page 56): 

a. For Repository identifier, the value is the unique identifier for the LDAP repository that 

you entered in the General Properties (Figure B-3). This identifier uniquely identifies 

the repository, for example: c0y0te. 

b. For Directory type, select the type of LDAP server to which you connect from the 

drop-down list of LDAP directory types. For example, for use with an openLDAP server, 

select the Custom value. 

c. For Primary host name, specify the host name of the primary LDAP server. This host 

name is either an IP address or a Domain Name System (DNS) name. 

d. For Port, type the LDAP server port. The default value is 389, which is not a Secure 

Sockets Layer (SSL) connection. For some LDAP servers, you can specify a different 

port for a non-SSL or SSL connection. 

e. For Failover host name, specify the host name of the failover LDAP server. You can 

specify a secondary directory server to use in the event that your primary directory 

server becomes unavailable. 

f. For Support referrals to other LDAP servers, specify how referrals that are encountered 

by the LDAP server are handled. A referral is an entity that is used to redirect a client 

request to another LDAP server. A referral contains the names and locations of other 

objects. It is sent by the server to indicate that the information that the client requested 

can be found at another location, possibly at another server or several servers. The 

default value is ignore. 

g. For Bind distinguished name, type the distinguished name (DN) for the application 

server to use when binding to the LDAP repository. If no name is specified, the 

application server binds anonymously. In most cases, bind DN and bind password are 

required. However, when anonymous bind can satisfy all of the required functions, a 

bind DN and password are not required. 

h. For Bind password, type the password for the application server to use when binding to 

the LDAP repository. 

i. For Login properties, type the property names to use to log into the application server, 

for example, uid. This field accepts multiple login properties that are delimited by a 

semicolon (;). All login properties are searched during login. If multiple entries or no 

entries are found, an exception is thrown. For example, if you specify the login 

properties as uid and the login ID as Bob, the search filter searches for uid=Bob. When 


the search returns a single entry, authentication can proceed. Otherwise, an exception 

is thrown. 

j. For Certificate mapping, to map X.509 certificates into an LDAP directory, choose 

either EXACT_DN or CERTIFICATE_FILTER. Specify EXACT_DN to use the specified 

certificate filter for the mapping. 

k. For Certificate filter, type the filter certificate mapping property for the LDAP filter. The 

filter is used to map attributes in the client certificate to entries in the LDAP repository. 

l. Select Require SSL communications to enable secure socket communication to the 

LDAP server. When enabled, the SSL settings for LDAP are used, if they are specified. 

m. Click OK to add the new repository. 

Figure B-4 Repository configuration 

3. On the next page (Figure B-5 on page 57), add the repository details: 

a. For Distinguished name that uniquely identifies this set of entries in the realm, add the 

DN that uniquely identifies this set of entries in the realm. If multiple repositories are 

included in the realm, define an additional DN that uniquely identifies this set of entries 

within the realm, for example: dc=tucson,dc=ibm,dc=com. 

b. For Distinguished name of a base entry in this repository, add the LDAP DN of the 

base entry within the repository. The entry and its descendents are mapped to the 

subtree that is identified by the unique base name entry field, for example: 

dc=tucson,dc=ibm,dc=com. 

If this field is left blank, the subtree defaults to the root of the LDAP repository. 


c. Click OK to save the changes. 

Figure B-5 Repository details 

As shown in Figure B-6, the repository was added successfully to the realm. 

Figure B-6 Repositories in the realm 

4. Click Apply to save the configuration. 

5. In the Messages box (Figure B-7), click Save to save the changes to the configuration. 

Figure B-7 Messages Box - Saving and reviewing the changes 

B.4 Setting additional properties 

Back in the General Properties window (Figure B-2 on page 54), you can configure additional 

properties, including performance, LDAP entity types, and group attribute definition 

(Figure B-8). While this section provides only an overview, see the product documentation for 

details. 

Figure B-8 Additional properties 


► Configuring performance 

Use the page shown in Figure B-9 to minimize the impact to performance by adding open 

connections and contexts to internally maintained pools and reusing them. These settings 

also minimize performance impacts by maintaining internal caches of retrieved data. 

Figure B-9 shows the performance settings that we used in our environment. 

Figure B-9 Adjusting performance settings 

► Setting up LDAP entity types 

Use the page shown in Figure B-10 to list entity types that are supported by the member 

repositories or to select an entity type to view or change its configuration properties. You 

must configure the supported entity types before you can manage this account with users 

and groups in the administrative console. The “Base entry for the default parent” column 

determines the repository location where entities of the specified type are placed on write 

operations by user and group management. 

After you add or update your federated repository configuration, go to the Security → 

Secure administration, applications, and infrastructure panel and click Apply to 

validate the changes. 

Figure B-10 Editing the Directory Structure settings 


► Specifying the group attribute definition 

Use the page shown in Figure B-11 to specify the name of the group membership 

attribute. Every LDAP entry includes this attribute to indicate the group to which this entry 

belongs. 

Figure B-11 General Properties 

As shown in Figure B-12, add a new members attribute collection to your configuration. In 

our case, the name of the member attribute is member, and the Object class is 

groupOfNames. 

Figure B-12 LDAP group DN to Tivoli Integrated Portal member mapping 

After you configure any of these additional properties, save your settings and apply the 

changes. 

Important: When you finish adding or updating your federated repository configuration, go 

to the Security → Secure administration, applications, and infrastructure panel and 

click OK then Apply to validate the changes. 


B.5 Managing users and groups 

To manage users and groups, from the Tivoli Integrated Portal console main window, select 

Security → Users and Groups. Then choose whether you want to manage users or groups: 

► Managing users 

Use the Manage Users window (Figure 3-4) to display a list of users that match your 

search criteria. You can perform additional tasks such as view more information about a 

user, change information about a user, add a new user, delete users, or duplicate the 

group assignments of a user for other users. You can also customize how the information 

is displayed in the table, as well as create and save customized search filters. 

Figure 3-4 Manage Users window 

► Managing groups 

Use the Manage Groups window (Figure 3-4) to list groups that match your search criteria. 

You can perform additional tasks such as view more information about a group, change 

information about a group, add a new group, delete groups, or duplicate the group 

assignments of a group for other groups. You can also customize how the information is 

displayed in the table, as well as create and save customized search filters. 

Figure B-13 Manage Groups window 


C 

Appendix C. Installing Tivoli Directory Server 

v6.2 

The Tivoli Directory Server uses the Lightweight Directory Access Protocol (LDAP) to provide 

a trusted identity data infrastructure for authentication in the following ways: 

► It provides identity management for companies that want to deploy a robust and scalable 

identity infrastructure. 

► It uses LDAP identity infrastructure software and meets LDAP v3 industry compliance 

standards. 

► It enhances proxy server capabilities with flow control for managing requests and paging 

search results for single and multiple partitions and a smart fail-back mechanism to 

restore servers safely. 

► It maintains high availability with master/subordinate and peer-to-peer replication 

capabilities and scheduled online or offline backup and remote restore. 

► It supports virtual list views so that you can scroll forward or backward through entries in a 

large sorted data set and can record deleted entries. 

► It supports leading platforms, including IBM AIX, i5/OS®, z/OS®, Sun Solaris, 

Microsoft Windows Server, HP-UX, and SUSE® and Red Hat® Linux distributions. 

In this appendix, we explain how to install and configure Tivoli Directory Server v6.2 in a 

Windows Server environment. 


C.1 Installing the server 

To install the server: 

1. In the ./tdsV6.2/tds/ directory, select the install_tds file to launch the installation. 

2. When prompted by the installation wizard (Figure C-1), select a language for the 

installation and click OK. 

Figure C-1 Selecting the language 

3. In the welcome panel, click Next. 

4. In the license agreement panel (Figure C-2), click I accept both the IBM and non-IBM 

terms and then click Next. 

Figure C-2 License agreement panel 


5. In the next window (Figure C-3) choose the type of installation, which normally to select 

Typical. Then click Next. 

Figure C-3 Selecting the type of installation 

6. Provide a DB2 user ID and password (Figure C-4). 

Figure C-4 Specifying a user ID for the DB2 administrator 

Appendix C. Installing Tivoli Directory Server v6.2 63

While you can select an existing user, you must ensure that the user is a member of the 

DB2ADMNS and DB2USERS groups as illustrated in Figure C-5. 

Figure C-5 User group membership of the DB2 administrator 

Back in the window shown in Figure C-4, click Next. 

7. In the installation summary panel (Figure C-6), if all the options are correct for your 

environment, click Install. 

Figure C-6 Summary before the installation 


Figure C-7 shows the installation process starting. This process might take a while, 

depending on the hardware. 

Figure C-7 DB2 installation progress 

8. After the installation completes successfully, in the installation window (Figure C-8), click 

Finish to continue with the configuration. 

Figure C-8 Successful installation 


C.2 Configuring the server instance 

The Tivoli Directory Server Instance Administration Tool (Figure C-9) starts automatically 

upon completion of the Tivoli Directory Server installation. To configure the server instance: 

1. In the Tivoli Directory Server Instance Administration Tool window, click Manage. 

Figure C-9 Tivoli Directory Server Instance Administrator Tool window 

In the left pane of the next window (Figure C-10 on page 67), you see some of the 

configuration tasks that can be performed: 

– Change the administrator user or password 

– Perform database related tasks such as backup and restore operations or tune the 

database performance settings. 

– Import existing LDAP Data Interchange Format (LDIF) files (contain the Object 

entries of the LDAP tree). This Export/Import function can also be used to create a 

backup of critical LDAP information. 


Figure C-10 Tivoli Directory Server Configuration Tool 

2. Make changes as required for your environment by selecting the appropriate options. 

Then proceed with the additional changes as documented in the following steps. 

3. Invoke the Web Administration Tool. From the Windows desktop, click Start → All 

Programs → IBM Tivoli Directory Server 6.2 → Web Administration Tool. The default 

browser opens. 

4. In the initial window (Figure C-11), enter the administrator user ID and password. The 

default user ID is superadmin and the default password is secret. Then click Login. 

Figure C-11 Console administrator login 


5. After a successful logon, in the Console administration pane (Figure C-12), change the 

default login user ID and password: 

– To change the login name, from the left pane, click Change console administrator 

login. 

– To change the password, from the left pane, click Change console administrator 

password. 

Note: This user ID and password change is not for the Windows Administrator user. For 

more information, see the documentation for Tivoli Directory Server in the information 

center at the following address: 

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?toc=/com.ib 

m.IBMDS.doc/toc.xml 

Add a console server connection by clicking Manage console servers and then clicking 

Add. 

Figure C-12 Console administration panel 

6. In the Manage console servers pane (Figure C-13), click Edit to review or change the 

parameters for the connection between the Web Admin tool and the LDAP Server 

Instance. 

Figure C-13 Manage console servers pane 


7. In the Edit server pane (Figure C-14), enter the server host name or IP address. Then 

click OK. 

Port: To view the Port Settings, in the Server Instance Administration Tool, select the 

instance and click view. 

Figure C-14 Properties of the server connection 

8. Log out of the Console administration window and log in again by clicking the here link. 

Now the login name has changed to the Directory server login. 

9. In the Directory server login window (Figure C-15), from the LDAP Server Name list, 

select an LDAP server if more than one is available. The User DN (cn=root in our case) is 

configured during the configuration of the first server instance. Type the password and 

click Login. 

Figure C-15 Directory Server Login 

Now you can start to build your directory structure by creating the different groups and users. 

Figure C-16 on page 70 through Figure C-20 on page 72 show examples of the different 

options that are available to manage your Tivoli Directory Server LDAP directory. 


Figure C-16 shows the welcome page. 

Figure C-16 Web Administration welcome page 

By selecting Server administartion in the left pane in Figure C-16, you can edit the port 

setting or the administrator group, or you can set a password policy. You can also start and 

stop the server. 

Figure C-17 shows the Manage users pane. 

Figure C-17 Manage users pane 


Figure C-18 shows the Manage groups pane. 

Figure C-18 Manage groups pane 

Figure C-19 and Figure C-20 on page 72 show the Directory management panes for 

modifying existing directory entries. 

Figure C-19 Directory Content Management 


Figure C-20 Content Management User 

More information: For a detailed description, see the Tivoli Directory Server 

documentation in the information center at the following address: 

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?toc=/com.ibm.I 

BMDS.doc/toc.xml 


D 

Appendix D. Installing openLDAP in a SUSE 

Linux environment 

In this appendix, we explain how to install openLDAP in a SUSE Linux environment. The 

SUSE Linux distribution contains the required packages for Lightweight Directory Access 

Protocol (LDAP) support. 


D.1 Installing the required LDAP packages 

To implement an LDAP server on a SUSE Linux Enterprise Server (SLES) 10 system, install 

the following packages: 

► openldap2 

► openldap2-clients 

► openldap2-devel 

► nss_ldap 

► pam_ldap 

To search for the LDAP packages: 

1. Enter the following command: 

yast2 sw_single & 

2. In the YaST2 installation window (Figure D-1): 

a. In the Search field, type the word ldap and click Search to obtain the list of packages 

that contain ldap in their name. 

b. Select the required packages (using the check boxes) and click Accept. 

Figure D-1 YaST2 installation window 

The packages are now being installed. Wait until the entire process completes. 


D.2 Configuring the LDAP server 

From YaST, choose the LDAP server. In the LDAP Server Configuration window (Figure D-2), 

select Yes to have the LDAP server automatically started when booting the server. 

Figure D-2 Selecting to start the LDAP server 

D.3 Configuring the LDAP client 

To configure the LDAP client: 

1. Enter the following command: 

yast2 ldap & 

Appendix D. Installing openLDAP in a SUSE Linux environment 75

2. In the LDAP Client Configuration window (Figure D-3): 

a. Under User Authentication, select Use LDAP. 

b. In the Address of LDAP Servers field, enter the LDAP server IP address. 

c. In the LDAP base DN field, enter the LDAP distinguished name (DN). Alternatively, you 

can click Fetch DN after you enter the LDAP server name (and assuming the service is 

started). In this case, a window is displayed in which you can select the DN. 

d. Click Advanced Configuration. 

I 

Figure D-3 LDAP Client Configuration window 


3. In the Advanced Configuration window (Figure D-4), click the Client Settings tab and 

enter the values under Naming Contexts. The values should match the base DN specified 

in the LDAP Client Configuration window (Figure D-3 on page 76). 

Figure D-4 LDAP Advanced Configuration - Client Settings tab 


4. Click the Administration Settings tab (Figure D-5) and click Accept to complete the 

LDAP client configuration. 

Figure D-5 Advanced Configuration - Administration Settings tab 

5. Verify that your LDAP client is properly configured and working by entering your LDAP 

server settings in the LDAP Browser dialog (Figure D-6). 

Figure D-6 LDAP Browser LDAP Server connection settings 


If successful, you see a view of the LDAP tree that lists all the configured entries on the 

LDAP server (Figure D-7). 

Figure D-7 LDAP Browser list 

At this stage, the installation is completed. You can now create and configure users and 

groups according to the directory structure you want. 



Appendix E. LDAP structure overview 

E 

In this appendix, we provide a brief overview of the LDAP structure. The structure of the 

directory used with LDAP looks like a upside down tree, with the root on the top. This is 

known as a directory information tree (DIT). The directory start with a root directory and 

branches in the different sections. 

The root of a directory service structure is tied to a domain. There are some circumstances 

where it is necessary to divide the information into two or more domain trees or directory 

information trees. This is known as a domain forest. 

Similar to a file directory on a PC, the branches in the directory service tree contain 

information or specific attributes about an object. Some of the object attributes are built by the 

position of that object within the tree structure, and some attributes are given separately. 

Figure E-1 on page 82 shows an example of a directory tree. In this example, the root of the 

directory is the country information, followed by the company name, then an identifier for the 

city, and underneath, branches for user, group or even printers. 


Figure E-1 Structure of an LDAP directory database 

Each object must have a unique identifier, known as the distinguished name (DN). This DN is 

built from its relative distinguished name (RDN), and the RDN is a construct of some of the 

object’s attributes followed by the parent objects’ DN. 

As a way to illustrate the concept of DN and RDN, consider a full file name on a PC. As shown 

in Example E-1, the full name, including the whole path, can be thought of as the DN. The 

RDN is the short file name, relative to the subdirectory where the file is located. 

Example E-1 DN and RDN 

DN of ntuser.dat =C:\WINDOWS\system32\win.com 

RDN of win.com = win.com 

the DN is now build up of the parent DN’s 

DN of=c:\ 

DN of=WINDOWS 

DN of=system32 

when the object “win.com” is now copied to “c:\WINDOWS\” 

the DN changes to “C:\WINDOWS\win.com” but the object and it’s attributes are the 

same. 

The DN is not fixed for an object and can change. In our example, when the file is moved to a 

different subdirectory, the full file name (DN) changes. This is also the case for the DN of an 

object in Directory Services. Whenever some attributes of the object change, the DN of that 

object also changes. 

To uniquely identify objects, the LDAP server assigns a Universally Unique Identifier (UUID) 

to each object. Compared to the DN, the UUID never changes until the object is deleted. 


c=us 

o=ibm o=xyz 

ou=tucson ou=raleigh 

cn=groups cn=users cn=printers 

cn=admins 

cn=users 

cn=diskAdmin 

cn=tapeAdmin 

cn=superAdmin 

ou=new york 

deviceID=printer1 deviceID=printer37

Example E-2 shows an illustration from the test directory, which contains DS8000 user 

information that we used in preparation of this paper. 

Example E-2 User attributes 

dn: uid=diskAdmin,cn=users,ou=tucson,o=ibm,c=us 

objectclass: inetOrgPerson 

objectclass: person 

objectclass: organizationalPerson 

cn: disk 

sn: admin 

mail: diskadmin@us.ibm.com 

uid: diskAdmin 

userpassword: passw0rd 

uuid: 25a8c2e8-1a3f-4ac4-b1b5-32d9b9188000 

This example shows how the DN was built from different attributes of the user. (LDAP lets you 

define which attributes must be listed for a valid DN. For our client for DS8000 users, we 

configured a default of cn=users,ou=tucson,o=ibm,c=us and uid as specific user attribute. 

See Figure A-8 on page 45. 

Appendix E. LDAP structure overview 83


Related publications 

IBM Redbooks 

The publications listed in this section are considered particularly suitable for a more detailed 

discussion of the topics covered in this paper. 

For information about ordering these publications, see “How to get Redbooks” on page 85. 

Note that some of the documents referenced here may be available in softcopy only. 

► Managing Disk Subsystems using IBM TotalStorage Productivity Center, SG24-7097 

► Patterns: Pervasive Portals Patterns for e-business Series, SG24-6876 

► Understanding LDAP - Design and Implementation, SG24-4986 

Other publications 

These publications are also relevant as further information sources: 

► IBM System Storage DS8000: Command-Line Interface User’s Guide, SC26-7916 

► IBM System Storage DS8000: Introduction and Planning Guide, GC35-0515 

How to get Redbooks 

Help from IBM 

You can search for, view, or download Redbooks, Redpapers, Technotes, draft publications 

and Additional materials, as well as order hardcopy Redbooks, at this Web site: 

ibm.com/redbooks 

IBM Support and downloads 

ibm.com/support 

IBM Global Services 

ibm.com/services 



Index 

A 

administration for users, groups, and roles 33 

administration, applications, and infrastructure settings 

52 

administrative security 52 

administrator role 2, 34 

application security 52 

Authentication Client 8 

Authentication Server 7–8 

B 

base entry added to a realm 54 

basic user management 1–2 

C 

CA (certificate authority) 15 

certificate authority (CA) 15 

certificate creation 13 

chauthpol command 31 

Copy Services operator role 2, 34 

D 

data repository 5 

DB2 Server v9 for Windows 39 

device server 20 

directory 5 

Directory Information Tree (DIT) 81 

Directory Services 1 

LDAP 5 

Directory Services-based user authentication 1 

directory structure 69 

distinguished name (DN) 55, 82 

DN (distinguished name) 82 

DNS (Domain Name System) 6 

domain 81 

forest 81 

Domain Name System (DNS) 6 

DS CLI 4 

DS GUI 3 


basic user management and access 2 

benefits of LDAP authentication for administrators and 

users 8 

configuration for LDAP authentication 22 

HMC 2 

LDAP authentication 1, 7 

E 

Enterprise Storage System Network Interface (ESSNI) 

client 3, 7 

server 2–3, 7 

ESS service port 23 

ESSNI (Enterprise Storage System Network Interface) 

client 3, 7 

server 2–3, 7 

F 

federated repositories 53 

G 

group administration 33 

group attribute definition 59 

group management 60 

H 

Hardware Management Console (HMC) 2 

HMC (Hardware Management Console) 2 

I 

iKeyman utility 14 

J 

jython 19 

L 

LDAP (Lightweight Directory Access Protocol) 6–7 

authentication 

benefits 8 

configuration in Tivoli Storage Productivity Center 

51 

for DS8000 1 


entity types 58 

group mappings 

DS CLI 35 

DS GUI 34 

Tivoli Storage Productivity Center roles 36 

implementation for the DS8000 11 

installation of servers 12 

structure overview 81 

SUSE Linux 

client configuration 75 

required packages 74 

Lightweight Directory Access Protocol (LDAP) 1, 6–7, 

33, 61 

authentication 

benefits 8 

configuration in Tivoli Storage Productivity Center 

51 

for DS8000 1 


entity types 58 

group mappings 


DS CLI 35 

DS GUI 34 

Tivoli Storage Productivity Center roles 36 

implementation for the DS8000 11 

installation of servers 12 

structure overview 81 

SUSE Linux 

client configuration 75 

required packages 74 

server configuration 75 

Lightweight Third Party Authentication (LTPA) 19 

logical operator role 2, 34 

Lotus Domino 6 

lsauthpol command 29, 31 

LTPA (Lightweight Third Party Authentication) 19 

LTPA keys 

CLI to export and import 19 

GUI to export and import 21 

M 

Manage Groups 60 

Manage Users 60 

Microsoft Active Directory 7 

mkuser command 5 

monitor role 3, 34 

N 

no access role 3, 34 

O 

openLDAP 13, 73 

for Linux 7 

installation in a SUSE Linux environment 73 

P 

performance configuration 58 

physical operator role 2, 34 

port number 23 

R 

RDN (relative distinguished name) 82 

realm 53 

adding a base entry 54 

Redbooks Web site 85 

Contact us viii 

referral 55 

relative distinguished name (RDN) 82 

repository 52 

Request for Comments (RFCs) 6 

RFC (Request for Comments) 6 

role-based authorization, Tivoli Storage Productivity Center 

36 

roles 2 

administration 33 


S 

SAS (Storage Authentication Service) 8 

server ID 52 

setauthpol command 30 

setauthserver command 30 

settruststore command 30 

showauthpol command 31 

single sign-on (SSO) 19 

SSPC (Storage System Productivity Center) 13 

SSPC (System Storage Productivity Center) 3 

Storage Authentication Service (SAS) 8 

Storage System Productivity Center (SSPC) 13 

SUSE Linux, openLDAP installation 73 

System Storage Productivity Center (SSPC) 3 

T 

testauthpol command 31 

Tivoli Directory Server 6, 61 

v6.2 installation 61 

Tivoli Directory Server Instance Administration Tool 66 

Tivoli Integrated Portal 1, 8, 13 

Tivoli Storage Productivity Center 

configuration for LDAP authentication 51 

Directory Services-based user authentication 1 

installation and configuration of servers 13 

installation of v4.1 39 

role-based authorization 36 

user administration for servers 36 

v4.1 installation on Windows Server 2008 39 

Tivoli Storage Productivity Center for Replication 46 

truststore file 8, 13 

copying 22 

creation 13 

U 

Universally Unique Identifier (UUID) 82 

user account repository 52 

user administration 33 

user management 60 

user repository 2 

user roles 2, 34 

UUID (Universally Unique Identifier) 82 

W 

Windows Server 2008, installation of Tivoli Storage Productivity 

Center v4.1 39 

wsadmin command 19 

X 

X.500 6 

Y 

YaST 75

IBM System Storage DS8000: 


Implement LDAP 

authentication for the 


Configure the 

required Tivoli 

Productivity Center 

v4.1 

Benefit from single 

sign-on 

REDP-4505-00 

Back cover 

Starting with release 4.2, the IBM System Storage DS8000 series 

offers the ability to replace the locally based user ID and password 

administration with a centralized directory based approach. This 

release also allows a single sign-on capability for multiple DS8000 

servers and possibly other servers in your environment. 

This IBM Redpaper publication helps DS8000 storage 

administrators understand the concepts and benefits of 

directories. It provides information that is required for 

implementing a DS8000 authentication approach based on the 

Lightweight Directory Access Protocol (LDAP). 

INTERNATIONAL 

TECHNICAL 

SUPPORT 

ORGANIZATION 

® 

Redpaper 

BUILDING TECHNICAL 

INFORMATION BASED ON 

PRACTICAL EXPERIENCE 

IBM Redbooks are developed 

by the IBM International 

Technical Support 

Organization. Experts from 

IBM, Customers and Partners 

from around the world create 

timely technical information 

based on realistic scenarios. 

Specific recommendations 

are provided to help you 

implement IT solutions more 

effectively in your 

environment. 

For more information: 

ibm.com/redbooks

IBM System Storage DS8000: LDAP Authentication - IBM Redbooks

Create successful ePaper yourself

Delete template?

Save as template?