LDAP Authentication for IBM DS8000 Systems · 1.4 Directory services and LDAP ... implementing a...

Redpaper

Front cover

LDAP Authentication for IBM DS8000 Systems

Bert Dufrasne

Juan Brandenburg

Leandro de Souza Lopes

Omar Hassan

International Technical Support Organization

LDAP Authentication for IBM DS8000 Systems

March 2018

REDP-5460-00

© Copyright International Business Machines Corporation 2018. All rights reserved.Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP ScheduleContract with IBM Corp.

First Edition (March 2018)

This edition applies to the IBM DS8870 with Licensed Machine Code (LMC) 7.7.50.xx.xx (bundle version 87.50.xxx.xx) or later and to the IBM Copy Service Manager (CSM) V.R.M.F (Version number, Release number, Modification number and Fix Pack number) 6.2.0.x or later.

This document was created or updated on March 1, 2018.

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

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiAuthors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiNow you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiStay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Chapter 1. Benefits of LDAP user authentication for the DS8000 . . . . . . . . . . . . . . . . . 11.1 DS8000 LDAP authentication overtime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Overview of LDAP-based authentication for the DS8000 . . . . . . . . . . . . . . . . . . . . . . . . 31.3 DS8000 basic user management and access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Directory services and LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Benefits for DS8000 administrators and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Chapter 2. Implementing LDAP authentication for the DS8000 . . . . . . . . . . . . . . . . . . . 92.1 The test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Installing the LDAP servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Installing the Copy Service Manager servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Updating the embedded Copy Service Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1 Download of IBM DSCLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.2 Checking CSM release installed on HMCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.3 Downloading CSM for upgrade on HMC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.4 Updating CSM on the HMC using DSCLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5 Defining the CSM topology for DS8000 LDAP authentication . . . . . . . . . . . . . . . . . . . 172.6 Configuring the CSM servers for LDAP authentication . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6.1 Configuring LDAP using CSM GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6.2 Configuring LDAP by using the CSM command line. . . . . . . . . . . . . . . . . . . . . . . 23

2.7 Creating or exporting the CSM truststore file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.7.1 Getting the truststore for CSM stand-alone servers . . . . . . . . . . . . . . . . . . . . . . . 25

Synchronizing the truststore file between two CSM servers . . . . . . . . . . . . . . . . . . . 26Exporting the CSM truststore file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.7.2 Creating the truststore file for CSM installed on the DS8000 HMC . . . . . . . . . . . 28Saving one or more CSM secure certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Creating the truststore file using the Java keytool . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.8 Enabling TLSv1 on CSM for old DS8000 systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.9 Configuring the DS8000 for LDAP authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.9.1 Using DSGUI on code levels older than R8.1 (88.10.x.x) . . . . . . . . . . . . . . . . . . . 35Creating a remote Storage Authentication Service policy . . . . . . . . . . . . . . . . . . . . . 36Testing the remote Storage Authentication Service policy . . . . . . . . . . . . . . . . . . . . 42Activating the remote Storage Authentication Service policy. . . . . . . . . . . . . . . . . . . 43Disabling the remote Storage Authentication Service policy . . . . . . . . . . . . . . . . . . . 46

2.9.2 Using DSGUI on code levels at R8.1 (88.10.x.x) or higher. . . . . . . . . . . . . . . . . . 48Enabling, disabling, and modifying the Local Administrator (recovery ID). . . . . . . . . 56

2.9.3 Configuring DS8000 LDAP authentication by using the DS CLI . . . . . . . . . . . . . . 59Disabling the remote authentication policy using DSCLI . . . . . . . . . . . . . . . . . . . . . . 63

2.9.4 Mapping LDAP users and groups to DS8000 Security Administrator role . . . . . . 64

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

Chapter 3. User, group, and role mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.1 DS8000 roles and authorization levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.2 Managing user mappings in DSGUI with code levels older than R8.1 . . . . . . . . . . . . . 69

3.2.1 Adding a user mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.2.2 Removing a user mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.2.3 Modifying a user mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.3 Managing user mappings by DSGUI on code levels higher than R8.1 . . . . . . . . . . . . . 723.3.1 Adding a new user mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.3.2 Removing a user mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.3.3 Modifying a user mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.4 Managing user mappings by DSCLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.4.1 Adding a user mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.4.2 Removing a user mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.4.3 Modifying a user mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Appendix A. Installing Copy Services Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77A.1 Preparation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78A.2 Install Copy Services Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Appendix B. Configuring Copy Services Manager for LDAP authentication using Microsoft Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

B.1 Configuring Copy Services Manager for LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84B.2 Testing Copy Services Manager for LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Appendix C. Exporting secure certificates in Google Chrome and Microsoft Internet Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

C.1 Certificate export on Microsoft Internet Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92C.2 Certificate export in Google Chrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Appendix D. LDAP structure overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99D.1 Directory tree details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100D.2 Directory with DS8000 user information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

iv LDAP Authentication for IBM DS8000 Systems

Notices

This information was developed for products and services offered in the US. This material might be available from IBM in other languages. However, you may be required to own a copy of the product or product version in that language in order to access it.

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 grant you any license to these patents. You can send license inquiries, in writing, to:IBM Director of Licensing, IBM Corporation, North Castle Drive, MD-NC119, Armonk, NY 10504-1785, US

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 jurisdictions 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 websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk.

IBM may use or distribute any of the information you provide in any way it believes appropriate without incurring any obligation to you.

The performance data and client examples cited are presented for illustrative purposes only. Actual performance results may vary depending on specific configurations and operating conditions.

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.

Statements regarding IBM’s future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.

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 actual people or business enterprises 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. The sample programs are provided “AS IS”, without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample programs.

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

Trademarks

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the web at “Copyright and trademark information” at http://www.ibm.com/legal/copytrade.shtml

The following terms are trademarks or registered trademarks of International Business Machines Corporation, and might also be trademarks or registered trademarks in other countries.

AIX®DS8000®Enterprise Storage Server®IBM®IBM Spectrum™

Jazz™Passport Advantage®Redbooks®Redpaper™Redbooks (logo) ®

System Storage®Tivoli®WebSphere®z/OS®

The following terms are trademarks of other companies:

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

Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Java, and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

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

vi LDAP Authentication for IBM DS8000 Systems

http://www.ibm.com/legal/copytrade.shtml

Preface

The IBM® DS8000® series includes the option to replace the locally based user ID and password authentication with a centralized directory-based approach.

This IBM Redpaper™ publication helps DS8000 storage administrators understand the concepts and benefits of a centralized directory. It provides the information that is required for implementing a DS8000 authentication mechanism that is based on the Lightweight Directory Access Protocol (LDAP).

Starting with DS8000 Release 7.5, directory-based authentication relies on IBM Copy Services Manager (CSM) that provides the interface (the CSM LDAP client) between the DS8000 and external LDAP servers.

Authors

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

Bert Dufrasne is an IBM Certified IT Specialist and Project Leader for IBM System Storage® disk products at the ITSO San Jose Center. He has worked at IBM in various IT areas. He 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. He holds a Master’s degree in Electrical Engineering.

Juan Brandenburg is a Product Field Engineer for the DS8000 in the United States. He is a graduate of the University of Arizona and holds a Bachelor’s of Engineering Management degree in Computer Engineering. His areas of experience for hardware include the DS8000 series and IBM System x servers. Juan has been working for IBM for nine years in the areas of storage engineering and disaster recovery solutions. He has many years of experience in scripting for Linux, IBM AIX®, and Microsoft Windows environments. Juan has continuously participated in IBM technical competitions and has won awards, such as the Distinguished Engineer Award for the 2006 Tech Connect competition and the Golden Eagle Coin in 2013, for excellent product delivery and customer satisfaction.

Leandro De Souza Lopes is a Product Field Engineer for the DS8000 and Copy Services Manager in Brazil. He has a Bachelor’s degree in Data Processing Technology at UNITUM (Faculdades Unidas de Itumbiara) and a graduate diploma in Information Security at UNIMINAS (União Educacional Minas Gerais - Uberlândia). He joined IBM in 2009, and has more than nine years of experience in the delivery of storage solutions. His areas of expertise include disk solutions (mid and high-end), Information Security, Microsoft Active Directory, SAN, and the Microsoft Windows and Linux operating systems. He has worked extensively supporting DS8000 especially in the Copy Services area.

Omar Hassan is a Technical Team Lead for CSM and Spectrum Control in Egypt. He has eight years of experience in the support field. He holds a degree in Management Information System from Middlesex. His areas of expertise include IBM Storage, SAN, and Security. He has written extensively on IBM Storage Subsystems.

Special thanks to Damian Trujillo (CSM Developer), Mark Hack (DS8000 Security Architect) and Jean Iyabi (DS8000 Product Field Engineer) for their contributions to this project.

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

Now you can become a published author, too!

Here’s an opportunity to spotlight your skills, grow your career, and become a published author—all at the same time! Join an ITSO residency project and help write a book in your area of expertise, while honing your experience using leading-edge technologies. Your efforts will help to increase product acceptance and customer satisfaction, as you expand your network of technical contacts and relationships. Residencies run from two to six weeks in length, and you can participate either in person or as a remote resident working from your home base.

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 publications in one of the following ways:

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

ibm.com/redbooks

� Send your comments in an email to:

[email protected]

� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400

Stay connected to IBM Redbooks

� Find us on Facebook:

http://www.facebook.com/IBMRedbooks

� Follow us on Twitter:

http://twitter.com/ibmredbooks

� Look for us on LinkedIn:

http://www.linkedin.com/groups?home=&gid=2130806

� Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks weekly newsletter:

https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm

� Stay current on recent Redbooks publications with RSS Feeds:

http://www.redbooks.ibm.com/rss.html

viii LDAP Authentication for IBM DS8000 Systems

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/


http://www.redbooks.ibm.com/contacts.html

http://www.facebook.com/IBMRedbooks

http://twitter.com/ibmredbooks

http://www.linkedin.com/groups?home=&gid=2130806

https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm

http://www.redbooks.ibm.com/rss.html

Chapter 1. Benefits of LDAP user authentication for the DS8000

By default, the DS8000 authentication is based on local user management (basic user management). Maintaining local repositories of users and their permissions is simple and convenient when dealing with only a few users and a few DS8000 servers or other systems. However, as the number of users and interconnected systems grows, authentication management quickly becomes difficult and time-consuming.

The IBM DS8000 storage system allows directory services-based user authentication. Starting with DS8000 Release 7.5, directory-based authentication relies on IBM Copy Services Manager (CSM) that provides the interface (the CSM LDAP client) between the DS8000 and external Lightweight Directory Access Protocol (LDAP) servers.

There are two possibilities for implementing the CSM server for DS8000 authentication:

� CSM can be installed in a stand-alone server running a supported operating system, which can be downloaded from IBM Support.

� Starting with firmware Release 8.1, Licensed Machine Code (LMC) 8.8.10.xx.xx, DS8000 includes the CSM code preinstalled on the Hardware Management Console (HMC).

In both cases, if you want to take advantage of the CSM LDAP client for DS8000 authentication, the CSM license and CSM activation are not required.

The benefits of a centralized user management approach can be substantial when considering the size and complexity of the overall IT environment. This chapter covers some of the benefits of this approach. Although the benefits from LDAP can be significant, you must also evaluate the substantial planning that is required and the complexity of deploying centralized directory services if they are not already in place.

This chapter also briefly covers the DS8000 local user management and user access methods. In addition, it provides an overview of the LDAP-based authentication, the technology used, and the potential benefits.

1

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

http://www.ibm.com/support/docview.wss?uid=ssg1S1005402

This chapter includes the following sections:

� DS8000 LDAP authentication overtime� Overview of LDAP-based authentication for the DS8000� DS8000 basic user management and access� Directory services and LDAP� Benefits for DS8000 administrators and users

2 LDAP Authentication for IBM DS8000 Systems

1.1 DS8000 LDAP authentication overtime

The process and products used for DS8000 LDAP-based authentication have changed over time.

Initially, the approach relied on IBM Tivoli® Storage Productivity Center. Up until release 5.1 of the IBM Tivoli Storage Productivity Center, the included Tivoli Integration Portal, was used to provide the interface between the DS8000 and the LDAP server. This solution is no longer supported as of September 2017. For additional information, see the Software lifecycle section of IBM Support.

Starting with Tivoli Storage Productivity Center 5.2.x, the embedded Tivoli Integrated Portal was removed from and replaced by the IBM JazzSM (Jazz™ for Service Management) product. JazzSM is an optional component of the Tivoli Storage Productivity Center installation process and was therefore not automatically installed. The Tivoli Storage Productivity Center family was rebranded as IBM Spectrum™ Control starting with release 5.2.8.x and the JazzSM support remained in place, but the Copy Services Manager based approach is preferred.

Generally, use CSM as the mechanism for DS8000 LDAP authentication. Remember that when CSM is used for the sole purpose of providing DS8000 LDAP authentication, no CSM licensing is required. If you are still using the Tivoli Storage Productivity Center or Spectrum Control based authentication, install CSM and start a plan to migrate to a CSM-based authentication.

1.2 Overview of LDAP-based authentication for the DS8000

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

Figure 1-1 DS8000 LDAP authentication architecture

Chapter 1. Benefits of LDAP user authentication for the DS8000 3

https://www.ibm.com/software/support/lifecycleapp/PLCDetail.wss?synkey=V720366V54463U04-V079077U03629A93-E700887N98035Y35

https://www.ibm.com/software/support/lifecycleapp/PLCDetail.wss?synkey=V720366V54463U04-V079077U03629A93-E700887N98035Y35

Communication between the DS8000 HMC and the administrative clients (DS CLI or DSGUI) is unchanged, compared to basic user authentication. The communication model still uses a client/server connection with the IBM enterprise storage server network interface (ESSNI) server on the HMC.

For example, when you use 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 or fully qualified domain name (FQDN) of the HMC. The user is prompted for a user ID and password.

When the DS8000 is set to use LDAP authentication, the ESSNI server, instead of validating the user request against the local registry, passes the user’s credentials to the authentication client (Liberty). The authentication client then validates them against the LDAP server. If the user’s credentials are valid, an authentication OK token is returned to the ESSNI server, which runs the command against the DS8000.

The major difference with basic authentication is that the DS8000 user IDs (as used by the DS CLI or the DSGUI) are no longer locally managed and stored at the HMC. Instead, they are managed and stored in an LDAP-managed directory server.

The HMC cannot communicate directly with the LDAP server. For DS8000 LDAP authentication, CSM is required and must be configured to use LDAP for single sign-on support.

The authentication method that is used (either basic or LDAP) is determined by setting an authentication policy in the DSGUI User Administration area. By default, the HMC is not configured to use LDAP. 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 for the DS8000 must be changed to Storage Authentication Service (SAS). The SAS policy includes all of 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 connection between the authentication server and the authentication clients. The communication between the LDAP server and the CSM servers can also be configured to use a secure connection through SSL, but that is not required.

1.3 DS8000 basic user management and access

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 HMC. The user repository is specific to a particular DS8000 and cannot be shared with other DS8000 servers in the enterprise. Therefore, if the same individuals must be both administrators and users of multiple DS8000 servers within the enterprise, their user IDs, passwords, and roles must be created separately and maintained individually for each DS8000 server.

An administrator user ID is pre configured in the DS8000 with the following defaults:

User ID adminPassword admin


Whenever a user is added, an initial password is assigned by the administrator. At the first sign-on, users must change their passwords. 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 must adhere to the following rules:

� Must be at least the minimum length as set by an administrator and no longer than 16 characters

� Must contain at least two types of characters from the three groups: alphabetic, numeric, and symbols

� Allowable characters are: a-z, A-Z, 0-9, and the symbol !@#$%&*()

� Cannot contain the user ID of the user

� Cannot be a previous password

General password settings include the time in days after which passwords expire and a number that identifies the number of failed logins that are allowed.

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

Monitor Allows access to list and show commands and provides access to all read-only, non-secure 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 role is assigned to any user account in the security repository that is not associated with any other user group)

Users are managed and administrative tasks are performed by using either the DSGUI (using a browser) or the DS CLI.


To work with user administration by using the DSGUI, complete these steps:

1. Sign on to the DSGUI by pointing your web browser to this URL:

https://HMCIPAddress_or_HMCFQDN:8452

2. From the menu on the left (Figure 1-2), select the Access menu (click the lock icon) and click Users.

Figure 1-2 Accessing the user management window by using the DSGUI

3. To create a user, on the Users window, click the Add User option (see Figure 1-3).

Figure 1-3 Selecting the option for add a user by using the DSGUI

4. In the Add User window (Figure 1-4), enter a user name and a temporary password. Specify a user role, and then click Add.

Figure 1-4 Adding a user and selecting a role for it

You can also use the DS CLI to perform user administration tasks. Example 1-1 illustrates the use of the mkuser command to add a user named csadmin.

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

dscli>mkuser -pw AB9cd&fg -group service,op_copy_services csadminDate/Time: April 11, 2014 1:00:34 PM MST IBM DSCLI Version: 7.7.5.23 DS: - DSCLI 7.7.5.23CMUC00133I mkuser: User csadmin successfully created.

You can use the DS CLI help command for further assistance.


1.4 Directory services and LDAP

Maintaining local repositories of users and their permissions is simple and convenient when you are dealing with only a few users and a few DS8000 servers or other systems. However, as the number of users and interconnected systems grows, it quickly becomes difficult and time-consuming to manage.

From a user access management perspective, directory services and LDAP can simplify the administrator’s tasks. Directory services typically provide a repository to store the location and other relevant information about resources, combined with an access method and related administrative services. Common examples in everyday life are a telephone directory and a library catalog. For a telephone directory, the objects listed are individuals, businesses, and, if applicable, the services that 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 that are necessary 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 websites. 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. This process results 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 can provide a focal point for integrating a distributed environment into a consistent and easily accessed system.

LDAP is an open industry standard that has evolved to meet these needs. LDAP defines a standard method to access and update information in a directory. LDAP has gained wide acceptance as the directory access method of the Internet and is, therefore, widely used 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 Request for Comments (RFCs) industry standard. 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 Requests for Comments page on the IETF.org website.


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

The implementation of a directory service is based on a client/server relationship. If an application expects data from an object that is 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 Understanding LDAP - Design and Implementation, SG24-4986.

The following directory servers are among the most common:

� Microsoft Active Directory

� OpenLDAP

1.5 Benefits for DS8000 administrators and users

When applications access a standard common directory that is properly designed 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

– On the web (for example, the IBM Security Directory Server Web Administration Tool)

– By using the WebSphere® Integrated Solutions of Version 5.2 of the Tivoli Storage Productivity Center

– By using the same user ID to access all DS8000 systems in your enterprise

– With password policy management

� Even though LDAP support can provide single sign-on (SSO) capability by using the same credentials to access multiple DS8000 servers, you can still create separate user IDs for one person and maintain those user IDs by using LDAP. This capability 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.

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 administer them.


https://technet.microsoft.com/en-us/library/hh831484(v=ws.11).aspx

http://www.openldap.org/



Chapter 2. Implementing LDAP authentication for the DS8000

This chapter explains how to implement Lightweight Directory Access Protocol (LDAP) authentication for the IBM DS8000 storage system.

The implementation involves the following high-level tasks:

1. Installing the LDAP servers.

2. Installing the Copy Service Manager servers (for CSM stand-alone servers).

3. Updating the embedded Copy Service Manager (for CSM on DS8000 Hardware Management Console (HMC)).

4. Defining the CSM topology that will be used (for CSM on DS8000 HMC).

5. Configuring the CSM servers for LDAP authentication.

6. Creating or exporting the CSM truststore file depending on the type of CSM installation (stand-alone installation or on HMC).

7. Configuring the DS8000 for LDAP authentication using the CSM servers as a proxy for authentication.


� The test environment� Installing the LDAP servers� Installing the Copy Service Manager servers� Updating the embedded Copy Service Manager� Defining the CSM topology for DS8000 LDAP authentication� Configuring the CSM servers for LDAP authentication� Creating or exporting the CSM truststore file� Enabling TLSv1 on CSM for old DS8000 systems� Configuring the DS8000 for LDAP authentication

2


2.1 The test environment

Figure 2-1 shows the layout of a typical LDAP environment that supports the DS8000 authentication by using stand-alone CSM servers. As depicted, you can set up a high availability environment by providing redundant installation key elements.

Figure 2-1 Typical LDAP environment using CSM stand-alone servers

Starting with IBM DS8880 with firmware Release 8.1 (License Machine Code 8.8.10.xx.xx), CSM is preinstalled on the HMC. If you simply want to take advantage of the CSM LDAP client for DS8000 LDAP authentication, the CSM license and CSM activation are not required.

Note: The DS8000 systems, CSM, and LDAP servers shown in Figure 2-1 can be spread across different physical sites because they communicate over the IP network.


Figure 2-2 shows an LDAP environment that supports DS8000 authentication, but using CSM servers that are embedded in the HMCs. In this specific example, only one of the DS8000 systems supports embedded CSM servers which can be used as proxy authenticators for the other DS8000 system. From the DS8K02 perspective, it is like CSM01 and CSM02 were stand-alone CSM servers.

Figure 2-2 LDAP environment using CSM installed into the DS8000 HMCs

To create and document scenarios described in this book, we used a mix of environments that are shown in Figure 2-1 on page 10 and Figure 2-2.

Regardless of topology, the following product releases were used in our test environment:

� All CSM servers are at release 6.2.0.

� LDAP01 and LDAP02 are installed on Microsoft Windows 2012 servers with Active Directory Domain Services and DNS Server roles enabled.

� CSM01 stand-alone is installed on a Microsoft Windows 2012 server.

� CSM02 stand-alone is installed on a Red Hat Enterprise Linux 7.4.

� DS8K01 is a DS8886 code level R8.2 (bundle 88.22.34.0). This system supports CSM on HMCs.

� DS8K02 is a DS8870 code level R7.5 (bundle 87.51.63.0).

Note: Even if your DS8000 has a CSM installed on the HMC, you can still use CSM stand-alone servers, if you prefer. In other words, you decide whether you want to use embedded, stand-alone, or a combination of both for your CSM environment.

Chapter 2. Implementing LDAP authentication for the DS8000 11

2.2 Installing the LDAP servers

As described in Chapter 1, “Benefits of LDAP user authentication for the DS8000” on page 1, the main benefit of a 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 server for DS8000 user authentication.

If you do not have an LDAP server installed, you need to install and configure one before moving to the next sections. The LDAP installation process depends on the LDAP solution that you chose. The following are examples of supported LDAP solutions and links where you can get installation instructions:

� Microsoft Active Directory � IBM Security Directory Server� OpenLDAP

2.3 Installing the Copy Service Manager servers

For CSM stand-alone servers setup, you must download and install CSM (if you do not have one available yet). CSM is the bridge between DS8000 systems and LDAP servers. That is why CSM is referred to as the proxy for LDAP authentication.

Appendix A, “Installing Copy Services Manager” on page 77 provides detailed instructions on how to download and install CSM on Microsoft Windows 2012 server.

Additional details for CSM release 6.2.0 on all supported platforms can be found in the IBM Knowledge Center page for CSM.

If you already have an available CSM server in your environment, make sure that latest CSM release is installed. For the latest available CSM release, refer to the downloads page on IBM Support.

Instructions for upgrading CSM to release 6.2.0 are available at Upgrading Copy Services Manager at IBM Knowledge Center.

Note: All servers and DS8000 systems are using the most updated patches available at the time of writing (November 2017).

Note: To keep redundant paths for DS8000 authentication, configure at least two LDAP servers.

Note: To keep redundant paths for DS8000 authentication, have at least two CSM servers available.


https://www.ibm.com/support/knowledgecenter/en/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/csm_icg_installing_parent.html

https://www.ibm.com/support/knowledgecenter/en/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/csm_icg_installing_parent.html



https://www.openldap.org/doc/

https://www.ibm.com/support/knowledgecenter/en/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/frg_t_upgrading.html

https://www.ibm.com/support/knowledgecenter/en/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/frg_t_upgrading.html

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/install-a-new-windows-server-2012-active-directory-forest--level-200-

https://www.ibm.com/support/knowledgecenter/en/SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ig_home.html

https://www.openldap.org/doc/

2.4 Updating the embedded Copy Service Manager

With the embedded CSM on HMC, the CSM release that came initially installed on the DS8000 HMC might be outdated.

Updating the HMC embedded CSM must be done exclusively through the IBM DSCLI tool (the same one used to manage DS8000 by command line).

2.4.1 Download of IBM DSCLI

Before updating CSM on HMC, make sure that you have the correct DSCLI release for your DS8000 code bundle level. To verify, complete these steps:

1. Go to the DS8000 Code Recommendation page.

2. Select your DS8000 model. Figure 2-3 shows an example for DS8880 R8.2.

Figure 2-3 DS8000 Code recommendation page

3. The DS8000 code bundle information page opens. Scroll down until you see a table containing all the available bundles for that specific DS8000 model. There you can find the correct DSCLI release for each code bundle and the CSM release originally installed on the HMC for that specific code bundle. Figure 2-4 shows an example where the DSCLI 7.8.22.87 is the correct release to be used with DS8880 bundle 88.22.34.0:

Figure 2-4 Recommended DSCLI release

IBM DSCLI is available for download at IBM Fix Central.

The instructions for installing DSCLI are available in IBM Knowledge Center.

2.4.2 Checking CSM release installed on HMCs

To verify the current CSM release installed on a DS8000 HMC, use the lsssoftware DSCLI command:

lssoftware -l -type csm -hmc all


http://www.ibm.com/support/docview.wss?uid=ssg1S1004456&myns=s028&mynp=OCST8NCA&mynp=OCSTXN8P&mynp=OCSTUVMB&mynp=OCHW2C2&mynp=OCHW2B2&mync=E

https://www.ibm.com/support/fixcentral/

https://www.ibm.com/support/knowledgecenter/ST5GLJ_8.2.0/com.ibm.storage.ssic.help.doc/f2c_clipreinstallgeninfo_3312g7.html

Example 2-1 shows an example where the CSM release on both HMCs is 6.1.5.

Example 2-1 Showing the current CSM release

dscli> lssoftware -l -type csm -hmc allDate/Time: August 28, 2017 5:51:32 AM MST IBM DSCLI Version: 7.8.22.87 DS: IBM.2107-75FWP21Type Version Status HMC====================================== CSM V6.1.5-a20170317-0921 Running 1 CSM V6.1.5-a20170317-0921 Running 2

2.4.3 Downloading CSM for upgrade on HMC

To download the latest CSM release, go to the Latest Downloads for IBM Copy Services Manager page.

The CSM installation file must be downloaded on the same workstation or server where the DSCLI was previously installed.

Complete the following steps, assuming CSM 6.2.0 as the latest release:

1. On the IBM Fix Central page, select IBM Copy Service Manager as the product, 6.2.0 as the installed version, and Linux as the platform. Figure 2-5 shows a summary of selected options.

Figure 2-5 Selection of CSM release to be updated on HMC

Note: HMC uses a Linux operating systems so, make sure you select Linux as platform






2. Be sure to download the appropriated Linux-x86_64 release. Figure 2-6 shows the correct package type you need to select.

Figure 2-6 CSM Package Linux-x86_64

3. When the download process is complete, take note of the folder path where the files were stored. In our example, the files are stored in the folder C:\Downloads\CSM_Linux, as shown in Figure 2-6.

Figure 2-7 Downloaded CSM files

2.4.4 Updating CSM on the HMC using DSCLI

Update the CSM on each HMC. In a dual HMC environment, update one CSM instance at a time.

The DSCLI command used for CSM update is installsoftware. You can find more information about that command at IBM Knowledge Center.

The following are the parameters for the installsoftware command:

-type csm

Specifies that software type of the installation is CSM.

-loc software_package

Specifies the full path of the specified software installation package to be installed.

-certloc certificate_location

Specifies the full path of the certificate file location.

Note: You can see that Signature file for DS8000 HMC upgrade is automatically selected along with the CSM package. You will need this file later.

Note: If your current CSM installation has active copy services sessions, you need to follow the best practices while applying maintenance to an active management server.


https://www.ibm.com/support/knowledgecenter/en/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/frc_t_reinstall_primary_server_active.html

https://www.ibm.com/support/knowledgecenter/en/ST5GLJ_8.2.2/com.ibm.storage.ssic.help.doc/f2c_cliinstallsoftware.html

-hmc 1 | 2 | all

Specifies the primary HMC hmc 1 or secondary HMC hmc 2 where the software is installed. The default is all (both CSMs will be updated at same time).

To effectively run the command, you need to use a DS8000 user ID that is part of the Administrator role (example the default admin user ID).

Example 2-2 shows how the CSM on HMC1 was updated by using DSCLI.

Example 2-2 CSM update on HMC1

dscli> installsoftware -type csm -loc C:\Downloads\CSM_Linux\csm-setup-6.2.0-linux-x86_64.bin -certloc C:\Downloads\CSM_Linux\csm-setup-6.2.0-linux-x86_64.bin.crt -hmc 1Date/Time: August 29, 2017 5:35:14 AM MST IBM DSCLI Version: 7.8.22.87 DS: IBM.2107-75FWP21CMUC00516I installsoftware: The file uploaded successfully.CMUC00517I installsoftware: Software CSM is successfully installed on 1.

dscli> lssoftware -l -type csm -hmc allDate/Time: August 29, 2017 5:38:13 AM MST IBM DSCLI Version: 7.8.22.87 DS: IBM.2107-75FWP21Type Version Status HMC====================================== CSM V6.2.0-a20170630-0759 Running 1 CSM V6.1.5-a20170317-0921 Running 2dscli>

For dual HMCs environments, the next step is to update the CSM on HMC2, as shown in Example 2-3.

Example 2-3 CSM update on HMC2

dscli> installsoftware -type csm -loc C:\Downloads\CSM_Linux\csm-setup-6.2.0-linux-x86_64.bin -certloc C:\Downloads\CSM_Linux\csm-setup-6.2.0-linux-x86_64.bin.crt -hmc 2Date/Time: August 29, 2017 5:41:29 AM MST IBM DSCLI Version: 7.8.22.87 DS: IBM.2107-75FWP21CMUC00516I installsoftware: The file uploaded successfully.CMUC00517I installsoftware: Software CSM is successfully installed on 2.

dscli> lssoftware -l -type csm -hmc allDate/Time: August 29, 2017 5:43:18 AM MST IBM DSCLI Version: 7.8.22.87 DS: IBM.2107-75FWP21Type Version Status HMC====================================== CSM V6.2.0-a20170630-0759 Running 1 CSM V6.2.0-a20170630-0759 Running 2dscli>

Note: In addition to the standard 1751 port, DSCLI also uses the port 1755 (TCP protocol) to transfer the CSM installation file to the HMC. That port needs to be open on any physical or software firewall standing between the workstation where DSCLI is installed and the DS8000 HMCs


2.5 Defining the CSM topology for DS8000 LDAP authentication

During the DS8000 configuration steps for enabling the LDAP authentication, you can use up to two CSM authentication servers (the second server works as a backup). There are many possibilities on how and where to install the two CSM servers:

� Stand-alone servers (many operating systems types):

– Microsoft Windows (physical and virtual servers)– Linux on Open Systems (physical and virtual servers)– Linux on IBM z Systems– AIX– z/OS®

� DS8000 HMCs

After both CSM servers (CSMA and CSMB) are configured for use with the same LDAP server and they are able to communicate over the IP network, you have many configuration options:

� CSMA installed in a physical Windows 2016 and CSMB installed in a virtual Red Hat Linux� CSMA installed in a z/OS and CSMB installed in a DS8000 HMC� CSMA installed in a DS8000 HMC from a specific DS8000 system and the CSMB is

installed in a DS8000 HMC from a different DS8000 system

There is not a direct recommendation for which topology to use. The following list consolidates some of the points to keep in mind when deciding about which topology to use:

� If you have several DS8000 systems that support embedded CSM on dual HMCs, you can decide to configure each system to use exclusively the two CSMs installed on each system. Following this approach, you do not need stand-alone servers. Each system will work independently. If that system is requiring any maintenance that will render both HMCs unavailable, the remaining DS8000 systems will not be affected.

On the other side, using this solution forces you to configure many CSM servers for LDAP authentication (if for instance you need to change the password for the LDAP user ID used by CSM to connect to LDAP servers, you will need to do that change on all CSMs) and you will use different authentication servers for each DS8000 configuration.

� If you have many DS8000 systems and some of them support embedded CSM on HMCs, you can select two different systems using one HMC in each of the selected two systems to centralize the LDAP authentication for all other systems. Following this approach, you do not need stand-alone servers, and all DS8000 systems will have two options for authentication. If you need to change some LDAP configuration settings on CSM (example: password changing for the LDAP user ID used by CSM to connect to LDAP servers), only two CSM servers need to be configured.

The process to configure the remote authentication on the DS8000 side will be simpler because the authentication servers to be used will always be the same ones. However, if DS8000 systems are located in different logical IP networks, you will have a more complex network configuration (including firewall management if that is the case). Another point to consider is that for any simultaneous maintenance on the two selected DS8000 systems, their HMCs become unavailable for some time, affecting authentication on all other DS8000 systems.


� If you decide to use one embedded CSM on DS8000 HMC and one stand-alone CSM installation as secondary, the configuration is simpler (only two CSM servers need to be configured or reconfigured during any LDAP changes) and the stand-alone CSM server will work regardless of DS8000 maintenance tasks (only make sure that the stand-alone server is not using disk resources from the same DS8000 that has the secondary CSM is installed on its HMC). This setup requires one CSM stand-alone server.

Another point to keep in mind with this solution is that some action plans provided by IBM Support during a troubleshooting can be different for each CSM server. This fact is because only IBM Remote Support is able to access the internal file system on HMC. In those situations, it is possible that part of provided action plan will be performed by you and part will be performed by IBM remote support personnel.

� If you decide to use stand-alone CSM servers in two different platforms (example CSMA on z/OS and CSMB on Windows), the configuration also is simple (only two CSM servers need be configured or reconfigured during any LDAP change) and the stand-alone CSM servers will work regardless of DS8000 maintenance (only make sure that both CSM servers are not using disk resources from the same DS8000 system). This setup requires two stand-alone CSM servers.

Another point to keep in mind for this solution is that some action plans provided by IBM Support during a troubleshooting can be different for each CSM server when they use different platforms. For example, if IBM Support requests to change some JAVA debug options, the path where that configuration file is stored can be different for each platform. You also need employees with minimum required skills for each platform to help IBM Support during data collection for troubleshooting and action plan implementation.

� If you have DS8000 systems older than DS8870 Release 7.2 (Licensed Machine Code (LMC) 7.7.20.xx.xx) and they cannot be upgraded to a new release (for example, a DS8800 system), you need to use CSM stand-alone servers if those systems will use CSM for LDAP authentication. The reason for that is because those old systems are able to use only the protocol TLSv1 (Transport Layer Security release 1) to communicate to CSM. By default, CSM only accepts communication using TLSv1.2. You can configure the CSM to be more permissive accepting connections using TLSv1. However, you need to access the file system where CSM is installed to change that configuration, and that is only allowed when CSM is installed in a stand-alone server.

Additional information about TLS can be found on:

� NIST SP 800-131a� The TLS Protocol Version 1.0� The TLS Protocol Version 1.1� The TLS Protocol Version 1.2� IBM DS8870 and NIST SP 800-131a Compliance, REDP-5069

Important: Using a setup where one CSM is stand-alone and the other one is installed on HMC requires that both the CSM secure certificates be exported and the Java truststore file be created as documented in 2.7.2, “Creating the truststore file for CSM installed on the DS8000 HMC” on page 28.

Note: Be aware that using TLSv1 instead of TLSv1.2 you are exposing the security of your environment to any uncovered weaknesses in TLS 1.0. Another point to keep in mind is that the new DS8000 systems might not accept to talk TLS 1.0 anymore (in particular, if they are configured to be in compliance with the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-131a). In that situation, dedicate CSM stand-alone servers only for the old DS8000 systems.


http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf

https://tools.ietf.org/html/rfc2246






2.6 Configuring the CSM servers for LDAP authentication

You can configure LDAP authentication on a CSM server by using the CSM GUI or the CSM command-line interface (CLI).

Regardless of the CSM interface that you use for LDAP configuration, you will need the following data before starting any configuration:

1. What kind of LDAP server are you using? For example, Microsoft Active Directory or Open LDAP.

2. What is the network port number used by your LDAP server (network port number that your LDAP server will accept incoming queries from the CSM servers)? For example, 389 or 639.

3. What are the Internet Protocol (IP) addresses from your LDAP servers or their fully qualified domain name (FQDN)?

4. What are the user ID and password created in the LDAP servers that you will configure on the CSM servers to query the LDAP user's credentials? You also need to know the full path in the LDAP server where that user is stored, such as “CN=lopesle,CN=CSM_Admins,DC=itso,DC=ibm,DC=com”.

5. Where in your LDAP domain should CSM look for users during the DS8000 authentication process? In most of cases, allow CSM to access all of your domains (regardless of Common Name (CN) where the user is stored in the LDAP internal structure), for example “DC=itso,DC=ibm,DC=com”. If for some reason you want to limit where in your LDAP domain CSM is allowed to query users, provide the specific LDAP path desired. For example, “CN=CSM_Admins,DC=itso,DC=ibm,DC=com” (in this example, CSM will only search for users with a CN of CSM_Admins in the "itso.ibm.com" LDAP domain).

Answers to those questions can normally be provided by your LDAP administrator. Some LDAP tools can be used by LDAP administrators to provide the correct LDAP structure and indicate where the user used as LDAP bind is stored. In Microsoft Active Directory environments, the most common tool is called dsquery.

The Microsoft dsquery tool is automatically installed on Microsoft Domain Controller servers and it can also be installed in a remote workstation depending on the Windows release:

� Remote Server Administration Tools for Windows 7 with Service Pack 1 (SP1) � Remote Server Administration Tools for Windows 8

Example 2-4 shows the dsquery tool being performed directly from the command line of one of Microsoft Domain Controllers servers.

Example 2-4 Searching for all user IDs starting with csml* directly from an AD server

C:\>dsquery user -name csml*"CN=csmldapuser,CN=Users,DC=itso,DC=ibm,DC=com"

C:\>

Example 2-5 shows the dsquery tool being run from a remote workstation command line.

Example 2-5 Searching for all user IDs starting with csml* from a remote Windows workstation

C:\>dsquery user -name csml* -s ldap01.itso.ibm.com -u ldapuser -p *Enter Password:


http://www.microsoft.com/en-us/download/details.aspx?id=7887

https://www.microsoft.com/en-us/download/details.aspx?id=28972





"CN=csmldapuser,CN=Users,DC=itso,DC=ibm,DC=com"

C:\>

Another common LDAP management tool is ldapsearch. The ldapsearch tool is available for many different platforms including AIX, Linux, and z/OS. Example 2-6 shows the ldapsearch tool being used from a Linux workstation against a Microsoft Active Directory LDAP server.

Example 2-6 Searching for all user IDs starting with csml* using ldapsearch

[workstation ~]$ ldapsearch -LLL -D "[email protected]" -h ldap01.itso.ibm.com -p 389 -b "dc=itso,dc=ibm,dc=com" "(cn=csml*)" dn -WEnter LDAP Password:

dn: CN=csmldapuser,CN=Users,DC=itso,DC=ibm,DC=com

[workstation ~]$

Additional details regarding the LDAP management tools area available at these websites:

� The ldapsearch tool � The dsquery tool

2.6.1 Configuring LDAP using CSM GUI

To configure LDAP on CSM, you must use a CSM user ID with an Administrator role. For the example in this book, the default user ID csmadmin is used.

Using a web browser, open the CSM GUI and enter the following commands:

� For CSM stand-alone servers:

https://<server_IP_or_FQDN>:9559/CSM/Example: https://csm01.itso.ibm.com:9559/CSM

� For CSM embedded on DS8000 HMC:

https://<HMC_IP_or_FQDN>/CSM/Example: https://ds8k01.itso.ibm.com/CSM

Figure 2-8 shows the CSM GUI login page:

Figure 2-8 CSM GUI login page

Note: the LDAP user ID credentials used to query LDAP while using dsquery and ldapsearch tools do not need to have an administrator role (it can be just a normal user in the LDAP repository).


https://technet.microsoft.com/en-us/library/cc725702(v=ws.11).aspx

http://www.openldap.org/software/man.cgi?query=ldapsearch&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html

https://technet.microsoft.com/en-us/library/cc725702(v=ws.11).aspx

http://www.openldap.org/software/man.cgi?query=ldapsearch&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html

After the credentials are authenticated by CSM, click Settings → Administration and then click the Modify link. Figure 2-9 shows an example where the following information was provided for LDAP configuration:

� Authentication method: Active Directory (if you are using any LDAP server other than Microsoft Active Directory, select LDAP instead of Active Directory).

� Authentication servers: For this book, the following servers are used (both using the port 389): ldap01.itso.ibm.com and ldap02.itso.ibm.com.

� Bind user ID: CN=csmldapuser,CN=Users,DC=itso,DC=ibm,DC=com. This is the exact output of dsquery command.

� Bind password: The LDAP password for the user ID csmldapuser (the bind user ID).

� Search base for users and groups: DC=itso,DC=ibm,DC=com. This will instruct CSM to look for users and groups stored on any part of the domain itso.ibm.com.

Figure 2-9 Basic LDAP configuration

Example 2-7 illustrates the advanced LDAP configuration using the Advanced tab. If you need to replicate the same LDAP configuration to another CSM server, you can use the Basic tab to create the initial configuration. As soon as it is tested and saved, you can copy the content of Advanced tab to just copy and paste it to all the other CSM servers you want to have LDAP configured on.

Example 2-7 Advanced LDAP configuration

<server description="IBM Copy Services Manager LDAP Registry"> <ldapRegistry baseDN="DC=itso,DC=ibm,DC=com" bindDN="CN=csmldapuser,CN=Users,DC=itso,DC=ibm,DC=com" bindPassword="{xor}HS0+JSo8PjE+Pi06PnIzMC86LDM6" host="ldap01.itso.ibm.com"

Note: If you are using a CSM installed on HMC, do not use customized LDAP ports. Only use the default port 389 (for unsecure connection between the CSM and LDAP servers) or the default port 636 (for secure connection between the CSM and LDAP servers). The reason for this instruction is that the internal firewall installed on HMC blocks any outgoing connection that uses customized ports. For the stand-alone CSM installations, you retain the flexibility to disable or manage the firewall rules directly on your host.


id="ldapregistry" ignoreCase="true" ldapType="actived" port="389" realm="ldapregistry"> <failoverServers name="failoverServers"> <server host="ldap02.itso.ibm.com" port="389"/> </failoverServers> </ldapRegistry> </server>

If you want to enable LDAP over Secure Sockets Layer (SSL) to better secure your environment, you must ask your LDAP administrator to create an SSL certificate and tell you which ports on the LDAP servers are accepting secure connections. In most cases, the port 636 is used as default. After you have the LDAP certificate file, you can configure the secure port used by your LDAP servers on CSM. Select Enable SSL and upload that file to CSM servers by clicking Load Certificate.

Figure 2-10 shows an example of enabling SSL using the Basic tab.

Figure 2-10 Enabling LDAP over SSL on the “Basic” tab


Figure 2-11 shows the same example using the Advanced tab.

Figure 2-11 Enabling LDAP over SSL on the “Advanced” tab

Click Test to verify that CSM is able to communicate with LDAP servers. Figure 2-12 shows an illustration of a successful communication.

Figure 2-12 CSM successfully contacting the LDAP servers

Click Save to save the LDAP configuration.

At this stage, the necessary configuration to make the CSM servers available to be used as authentication servers by DS8000 is complete.

You can find a more detailed example of LDAP configuration for CSM in Appendix B, “Configuring Copy Services Manager for LDAP authentication using Microsoft Active Directory” on page 83.

2.6.2 Configuring LDAP by using the CSM command line

The CSM command line (csmcli) is automatically installed on the CSM server during the normal installation process.

If you want to use csmcli from a remote workstation or server, you must download it from IBM Fix Central.




Figure 2-13 shows the csmcli package for Microsoft Windows that we installed in our testing environment.

Figure 2-13 Package of CSM remote CLI installation files for Windows

The process for csmcli installation and the initial configuration are covered in detail in IBM Knowledge Center.

From the CSM command line, you can use two different commands for LDAP configuration, based on your LDAP server type:

� mkadcfg: Used only to configure the Microsoft Active Directory server based authentication� mkldapcfg: Used to configure any LDAP server other than Microsoft Active Directory

The lsauthcfg command is used to show the current authentication configuration.

The default port used by csmcli is 9560 and csmcli always will try to access the localhost during the start process. To change the default port and the host to which csmcli should connect to, edit the csmcli file called repcli.properties.

Detailed instructions about this process and about each csmcli command can be found in the IBM Copy Services Manager Version 6 Release 2 - Command-Line Interface User's Guide.

Example 2-8 shows the process of configuring a Microsoft Active Directory on CSM using the command line.

Example 2-8 Configuring Microsoft Active Directory LDAP on CSM using the csmcli

Please enter a username for logging onto the servercsmadminPlease enter a password for logging onto the server>IBM Copy Services Manager Command Line Interface (CLI) Copyright 2007, 2015 IBM Corporation CLI Client Version: 6.2.0, Build: a20170630-0759 Authentication file: csmcli-auth.propertiesConnected to: Server: csm02.tuc.stglabs.ibm.com Port: 9560 UseREST: false Server Version: 6.2.0, Build: a20170630-0759

csmcli> lsauthcfg IWNR4962W [Sep 11, 2017 6:14:27 AM] No LDAP configuration found.csmcli> mkadcfg -server ldap01.itso.ibm.com:389;ldap02.itso.ibm.com:389 -username “CN=csmldapuser,CN=Users,DC=itso,DC=ibm,DC=com” -password S3cretpwd -baseDN “DC=itso,DC=ibm,DC=com” IWNR4950I [Sep 11, 2017 6:22:18 AM] Successfully updated the LDAP configuration

csmcli> lsauthcfgServer Port Role Type


http://www.ibm.com/support/docview.wss?uid=ssg1S7005399&aid=1

https://www.ibm.com/support/knowledgecenter/en/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/csm_installing_cli_on_remote_system.html

https://www.ibm.com/support/knowledgecenter/en/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/csm_installing_cli_on_remote_system.html

==================================================ldap01.itso.ibm.com 389 Primary Active Directoryldap02.itso.ibm.com 389 Failover Active Directorycsmcli>

2.7 Creating or exporting the CSM truststore file

For the communication between the DS8000 and the CSM authentication servers, the required secure certificates are stored in a file called the truststore.

The truststore file contains the secure certificate of each CSM server that DS8000 will use for LDAP authentication. Using the secure certificate of each CSM server allows the DS8000 to trust that CSM server. If the CSM server is ever reinstalled or you create a new CSM server using the same FQDN or IP address of the previous CSM server, its internal certificate will be different. In these cases, you must import it in truststore and reconfigure the DS8000 remote authentication.

The DS8000 requires a unique truststore file. If two CSM servers are used by DS8000 as LDAP authenticator, the unique truststore file must contain the certificate of both CSM servers.

The steps to get the CSM truststore file will be different depending on the type of CSM installation used in your environment:

� For CSM stand-alone servers, if you are using two CSM servers as authenticator proxy, you can synchronize the truststore file between them. Then, you can export the truststore file to use it while enabling the DS8000 remote authentication.

� For CSM installed on HMCs, you need to get the secure certificate of each CSM server and create the truststore file using the Java tool called keytool. The keytool tool is present in any Java Runtime Environment (JRE), which can be download from the Java website for many different platforms.

2.7.1 Getting the truststore for CSM stand-alone servers

Use the steps provided in this section only if all (maximum of two) CSM servers that you are using for enabling the DS8000 remote configuration are installed on stand-alone servers. If at least one of the CSM servers is installed on DS8000 HMC, go to 2.7.2, “Creating the truststore file for CSM installed on the DS8000 HMC” on page 28.

Each CSM server has an internal secure certificate that is stored in a truststore file. DS8000 uses that truststore file to implement secure communication between the DS8000 HMC and the CSM server.

If two CSM servers are used by DS8000 as LDAP authenticator, the same truststore file must be synchronized between the CSM servers and exported for use during the DS8000 remote policy configuration step.

Note: If you want to enable SSL for a Microsoft Active Directory server on CSM, you must use the CSM GUI because that option is only available for the mkldapcfg command.


https://www.java.com/

https://www.java.com/

Synchronizing the truststore file between two CSM serversUsing the CSM GUI, connect to one of the CSM servers for which you want to synchronize the truststore file. Click Settings → Advanced Tools and then click Synchronize.

Figure 2-14 shows the start of the truststore synchronization process.

Figure 2-14 Start of truststore synchronization process

The next step is to provide all information regarding the CSM destination server (the server that will receive the truststore file). Figure 2-15 shows an example where the CSM server csm01.itso.ibm.com is the destination server.

Figure 2-15 Data to remote access the CSM destination server

After the synchronization process is successfully completed, the message on Figure 2-16 is reported on CSM console. The message indicates that you must restart the services CSMAuth on the CSM destination server for the changes take effect.

Figure 2-16 Success on the truststore file synchronization

Make sure that you restart the CSMAuth service on the CSM destination of truststore synchronization. Additional details regarding how to stop and start the CSMAuth service are available at these websites:

� Stopping the Copy Services Manager authentication server on Windows � Starting theCopy Services Manager authentication server on Windows

Note: By default, the same port 9560 that is used for CSMcli access is also used for the truststore file upload on CSM destination server.


https://www.ibm.com/support/knowledgecenter/en/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/frg_t_stopping_csm_auth_server.html

https://www.ibm.com/support/knowledgecenter/en/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/frg_t_starting_csm_auth_server.html




The truststore file synchronization process also can be done in the command line by using the syncauthservice command. Detailed information about the syncauthservice command can be found at IBM Knowledge Center.

Exporting the CSM truststore fileThe CSM truststore file needs to be exported from CSM and uploaded onto the DS8000 HMC during the LDAP configuration process on DS8000.

From the workstation that you use to configure DS8000 LDAP authentication, start the CSM GUI. Connect to one of the CSM servers to be used as authentication server by the DS8000. Because both CSM servers already should have the same synchronized truststore file, you can use any of them. In the CSM GUI menu options, click Settings → Advanced Tools and then click Export. Figure 2-17 and Figure 2-18 show the process for exporting the truststore file.

Figure 2-17 Truststore export option from CSM GUI

Figure 2-18 shows that the key_itso.jks file now contains the truststore data.

Figure 2-18 The key_itso.jks file contains the truststore data

The default name for the truststore file is key_itso.jks. You can rename it if you want. The key here is to remember where you saved the truststore file to be able to proceed with the remaining steps on DS8000 LDAP configuration process.

Note: At the time of writing this document, the process for exporting the CSM truststore file is only supported by using the CSM GUI.


https://www.ibm.com/support/knowledgecenter/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/frg_r_cli_syncauthservice.html

2.7.2 Creating the truststore file for CSM installed on the DS8000 HMC

Use the instructions provided in this section to create the truststore file, when at least one of the CSM servers used as remote authenticator for the DS8000 is installed on the DS8000 HMC (embedded CSM).

In fact, the procedure can also be used when both CSMs are installed on stand-alone servers. In this case, you must use the secure certificate on port 9562 on both CSM stand-alone servers. The key for enabling the DS8000 remote authentication is to have the CSM server certificates available in a truststore file.

The first step is to save the secure certificate of each CSM server. The remaining steps are for consolidating one or more CSM certificates in a truststore file that DS8000 is able to use.

Saving one or more CSM secure certificatesThe CSM secure certificate used by DS8000 during the authentication process will change depending on where CSM is installed:

� If CSM is installed on the DS8000 HMC, the secure certificate to be used is the same one used by the default CSM login page:

https://FQDN_or_IP_of_the_CSM_server/CSM/

� If CSM is installed on a stand-alone server, the secure certificate to be used is the one configured for port 9562 (the internal Liberty WebSphere Application Server):

https://FQDN_or_IP_of_the_CSM_server:9562

You need to open your web browser and connect to the correct URL for the CSM server to get the secure certificate that you want to export.

The next steps were performed by using the Mozilla Firefox web browser. If you are using the Microsoft Internet Explorer or Google Chrome, use the instructions available in Appendix C, “Exporting secure certificates in Google Chrome and Microsoft Internet Explorer” on page 91.

1. Using a Firefox web browser, connect to the CSM server using the correct URL for the secure certificate that you want to export. Figure 2-19 shows an example where the CSM server is installed on DS8000 HMC. In this case, you need to get the secure certificate from the default CSM login page.

Figure 2-19 CSM login page: Default port 443 used for CSM installations on HMC


Figure 2-20 shows an example where the CSM is installed on a stand-alone server. In this case, you need to get the secure certificate configured on port 9562.

Figure 2-20 WS Liberty welcome page: Secure certificate to port 9562 (stand-alone server)

2. Regardless of which of the secure certificates you need to get, the process to save it is the same. Click the Lock icon on the left side of the URL and select the arrow located on the right side of the CSM FQDN (Figure 2-21).

Figure 2-21 Getting access to a secure certificate

3. Select More Information to get details about the secure certificate (Figure 2-22).

Figure 2-22 Getting the details about the secure certificate


4. In the next window, select Security on the top menu and click View Certificate (Figure 2-23).

Figure 2-23 Option View Certificate to get details about the secure certificate

5. In the Certificate Viewer window, select the Details tab and click Export (Figure 2-24).

Figure 2-24 Exporting the secure certificate


6. Select the folder where you want to save the exported certificate and provide a name for the file in which to save the certificate. Click Save to complete the exporting process (Figure 2-25).

Figure 2-25 Save the certificate to a file

7. Repeat these steps for the second CSM server to be used for DS8000 remote authentication.

Creating the truststore file using the Java keytoolThe DS8000 is able to use one or more CSM secure certificates that were previously saved. However, the certificates must be included in a Java truststore JKS file (a special file that is a repository for security certificates).

To create a new truststore file and import the CSM certificates into it, you need to use the keytool Java utility.

The keytool is included in the JRE. Most of environments (for example, your workstation or notebook) will have the JRE already installed. If you need to install the JRE, you can download it free of charge from the Java website.

After performing the instructions given in “Saving one or more CSM secure certificates” on page 28, you have CSM certificates and the file containing the secure certificate for each CSM server. In the following example, we use keytool to create the JKS truststore file and import the CSM certificates into that file.

For the examples shown here, we use the secure certificates from two CSM servers. The certificates were saved in C:\temp\csm01.crt and C:\temp\csm02.crt. The keytool utility is on a Microsoft Windows 7 Professional workstation (with JRE release 8).

Note: If you are using a CSM installed in a stand-alone server, you can use the keytool at this location:

<CSM Install folder>/IBM/CSM/liberty/wlp/IBM/Java/jre/bin/keytool

The following are some examples:

� Default path for keytool on a CSM installed in a Linux stand-alone server:

/opt/IBM/CSM/liberty/wlp/IBM/Java/jre/bin/keytool

� Default path for keytool on a CSM installed in a Windows stand-alone server:

C:\Program Files\IBM\CSM\liberty\wlp\IBM\Java\jre\bin\keytool.exe

If your CSM is installed on the DS8000 HMC, you need to use the keytool from a remote server or from your workstation where JRE is installed.


https://java.com/en/download/

Example 2-9 shows the details regarding the JRE release used in our examples.

Example 2-9 Showing the JRE details

C:\>java -versionjava version "1.8.0_141"Java(TM) SE Runtime Environment (build 1.8.0_141-b15)Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)C:\>

Complete the following steps:

1. In the Windows command prompt, go to the folder where the keytool is located (Example 2-10).

Example 2-10 Moving to the folder where the keytool is located

C:\>cd "Program Files (x86)\Java\jre1.8.0_141\bin"C:\Program Files (x86)\Java\jre1.8.0_141\bin>

2. Create a truststore file. Set a password for it and import the certificate from the first CSM server into that truststore file. Those three actions can be performed through a single keytool command:

keytool -import -trustcacerts -keystore <name_of_truststore> -storepass <password_for_the_truststore> -noprompt -alias <alias_for_your_certificate> -file <secure_certificate_to_be_imported>

Example 2-11 shows how the secure certificate from the first CSM server was imported into a truststore file called csmldapstore.jks located in folder C:\temp. The password for that truststore was set to passw0rd and the alias defined to the first CSM server was csm01. The full path for the CSM secure certificate that is being imported in the truststore file is C:\temp\csm01.crt.

Example 2-11 Creating the truststore file and adding the first CSM certificate into it

C:\Program Files (x86)\Java\jre1.8.0_141\bin> keytool -import -trustcacerts -keystore C:\temp\csmldapstore.jks -storepass passw0rd -noprompt -alias csm01 -file C:\temp\csm01.crtCertificate was added to keystore

C:\Program Files (x86)\Java\jre1.8.0_141\bin>

3. If you have one more CSM secure certificate to import, use a similar keytool command like shown in Example 2-11. However, use a different alias and a different path for the file containing the certificate taken from the second CSM server. You must keep the same truststore file name and password to have both CSM certificates in the same truststore file.

Note: You can use any name and password for the truststore file. You can decide where you will store the truststore file as well. The alias for each certificate can also be different from the one shown in Example 2-11. In any case, be sure to take note of the name, full path, and password specified for your truststore file.


Example 2-12 shows how the secure certificate from the second CSM server was imported into the truststore file csmldapstore.jks. The alias defined to the second CSM server was csm02 and that certificate was on the full path C:\temp\csm02.crt.

Example 2-12 Adding the certificate from the second CSM server to the truststore file

C:\Program Files (x86)\Java\jre1.8.0_141\bin> keytool -import -trustcacerts -keystore C:\temp\csmldapstore.jks -storepass passw0rd -noprompt -alias csm02 -file C:\temp\csm02.crtCertificate was added to keystore


4. You can use the following keytool command to provide a short list of all secure certificates existing inside of a truststore file:

keytool -list -keystore <full_path_of_the_truststore_file>

Example 2-13 shows how to use the keytool -list command to view the two CSM secure certificates imported into the truststore C:\temp\csmldapstore.jks. You need to provide the correct password defined for the truststore (in our example, it is passw0rd). During the DS8000 remote authentication configuration, the password for the truststore must also be provided so the DS8000 can open that truststore file and gain access to the CSM secure certificates.

Example 2-13 Listing the secure certificates in a truststore file

C:\Program Files (x86)\Java\jre1.8.0_141\bin>keytool -list -keystore C:\temp\Chrome\csmldapstore.jksEnter keystore password:********

Keystore type: JKSKeystore provider: SUN

Your keystore contains 2 entries

csm02, Oct 9, 2017, trustedCertEntry,Certificate fingerprint (SHA1): 85:D3:56:82:D0:D9:D8:74:E4:1B:8B:EB:40:84:D9:C2:BD:23:C5:6Ccsm01, Oct 9, 2017, trustedCertEntry,Certificate fingerprint (SHA1): 32:F6:5E:5D:88:69:FC:D0:F6:A9:92:59:36:FA:84:F3:3E:32:B7:D1


At this stage, all the steps for creating the truststore file required for DS8000 LDAP authentication are completed. Proceed to 2.9, “Configuring the DS8000 for LDAP authentication” on page 35 to configure the DS8000 using this truststore file.

Note: If you want to see the full content of certificates in a truststore file, use the flag -v as shown below:

keytool -list -v -keystore <full_path_of_the_truststore_file>


2.8 Enabling TLSv1 on CSM for old DS8000 systems

In 2.5, “Defining the CSM topology for DS8000 LDAP authentication” on page 17, we mentioned that DS8000 systems older than DS8870 with Release 7.2 (LMC 7.7.20.xx.xx), use TLS 1.0 for communication with CSM servers during the LDAP authentication.

If your system model is a DS8870 or newer, this section does not apply to you and you can proceed to 2.9, “Configuring the DS8000 for LDAP authentication” on page 35. If you have a DS8870 system with the microcode level lower than Release 7.2, you must upgrade, following the instructions found at IBM Support IBM Support.

To configure CSM to accept TLS 1.0 instead of the default TLS 1.2, you need to connect to the server where CSM is installed and edit the file bootstrap.properties, which can be found in these locations:

� AIX and Linux systems:

install_dir/liberty/wlp/usr/servers/csmAuth/bootstrap.properties

� Windows systems:

install_dir\liberty\wlp\usr\servers\csmAuth\bootstrap.properties

� z/OS systems:

path_prefix/opt/IBM/CSM/wlp/usr/servers/csmAuth/bootstrap.properties

In the bootstrap.properties file, replace the line ssl_protocol=TLSv1.2 with ssl_protocol=TLSv1 and save the file. The CSM authentication services must be restarted to reload the new value configured in the file bootstrap.properties. Additional details about how to stop and start the CSMAuth service are available at these websites:

� Stopping the Copy Services Manager authentication server on Windows � Starting theCopy Services Manager authentication server on Windows

Example 2-14 shows the default configuration of the bootstrap.properties file.

Example 2-14 Default configuration for the bootstrap.properties file for CSM authentication service

################################################################################This section is for the HTTPS settings of the IBM Copy Services Manager ##Authentication Server. ################################################################################https_port_var=9562ssl_protocol=TLSv1.2

Example 2-15 shows how the bootstrap.properties file updated for TLS 1.0 support.

Example 2-15 bootstrap.properties file configured to accept TLS 1.0 requests

################################################################################This section is for the HTTPS settings of the IBM Copy Services Manager ##Authentication Server. ################################################################################https_port_var=9562ssl_protocol=TLSv1


http://www.ibm.com/support/docview.wss?uid=ssg1S1004456&myns=s028&mynp=OCST8NCA&mynp=OCSTXN8P&mynp=OCSTUVMB&mynp=OCHW2C2&mynp=OCHW2B2&mync=E



2.9 Configuring the DS8000 for LDAP authentication

To configure the DS8000 for LDAP authentication, you can use either the DSGUI or the DSCLI. The LDAP and CSM servers must be running and the CSM servers must have been configured as explained in 2.6, “Configuring the CSM servers for LDAP authentication” on page 19.

The DSGUI has been gradually enhanced with successive code releases. To keep the compatibility between the new features and some legacy functions, two different DSGUI releases remain accessible:

� The current standard release is accessed by pointing your web browser at:

https://DS8000_HMC_IP:8452

� The previous DSGUI, which became available starting with Release 7.4 (code levels 87.4x.x.x), can be accessed at:

https://DS8000_HMC_IP:8452/previous/Login

Up until Release 8.1 (code level 88.10.x.x), the ability to configure LDAP authentication was available only using the previous DSGUI. Starting with Release 8.1 you can use the standard DSGUI.

2.9.1 Using DSGUI on code levels older than R8.1 (88.10.x.x)

The following three steps are required to enable the remote authentication on a DS8000:

1. Create a Storage Authentication Service (SAS) policy.2. Test your SAS policy to make sure it is working as expected.3. Activate the SAS policy.

Note: Even for code levels higher than R8.1 (88.10.x.x), the previous DSGUI is still available and can be used for configuring LDAP authentication. In fact, you will need to use the previous GUI if you are using Copy Services Resource Groups.

Details regarding Resource Groups can be found in IIBM System Storage DS8000 Copy Services Scope Management and Resource Groups, REDP-4758.

Another reason for using the previous DSGUI even with Release 8.1or later is if you want to keep more than one remote policy configured but inactive. For example, if you have a policy but you want to test a new one using different authentication servers (CSM servers), only the previous DSGUI allows you to create a second policy without overwriting the existing one.



Creating a remote Storage Authentication Service policyTo create a remote Storage Authentication Service policy, complete these steps:

1. Open the DSGUI by entering an administrative user ID and password, and then clicking Login, as shown in Figure 2-26.

Figure 2-26 DS8000 GUI login (previous then 88.10.x.x)

2. Select Remote Authentication from the Access menu from the lock icon, as shown in Figure 2-27.

Figure 2-27 Remote Authentication access

3. In the Remote Authentication window, select the Complex Name related to your DS8000 system, and from the Action menu select Create Storage Authentication Service Policy, as shown in Figure 2-28.

Figure 2-28 Creating a Storage Authentication Service Policy


4. When the Create Authentication Service Policy window that is shown in Figure 2-29 is displayed, provide the required information:

Figure 2-29 Authentication service configuration

Provide the following information:

– For SAS Policy Name, enter the name for the policy you are creating. You can define more than one policy but only one can be active at time.

– For Authentication Service URL, two options are available, depending on where your CSM server is installed:

• If the CSM server is installed on a stand-alone server, use this URL:

https://FQDN_or_IP_of_CSM:9562/CSMAuth/TokenService

Example:

https://csm01.itso.ibm.com:9562/CSMAuth/TokenService

• If the CSM server is installed on the DS8000 HMC, use this URL:

https://FQDN_or_IP_of_CSM/CSMAuth/TokenService

Example:

https://csm01.itso.ibm.com/CSMAuth/TokenService

Note:

� For CSM installations on a stand-alone server, the DS8000 should connect to port 9562 on the CSM server.

� For CSM installations on a DS8000 HMC, port 443 should be used by DS8000 because port 9562 is blocked by the internal HMC firewall for connections coming from the customer network (interface eth2 on the HMC).


– For Authentication Service URL (Primary), enter the URL that points to the first CSM server.

– For Authentication Service URL (Secondary), enter the URL that points to the second CSM server.

– For Authentication Service Client User ID, enter with an existing LDAP user ID to be used by the DS8000 to authenticate on the CSM servers.

– For Authentication Service Client Password and Confirm Authentication Service Client Password, enter the password defined to the LDAP authentication service client user ID (in this example, the password for the LDAP user ID csmldapuser).

5. Click Next to display the truststore file information page

Important: if one of your CSM servers is installed on a stand-alone server and the second one is installed on the HMC, you need to use the correct URL for each one of them.

Example:

� URL for the primary CSM (a stand-alone server):


� URL for the secondary CSM (installed on HMC):


The only requirement for this configuration is that you need to create the Java truststore file containing the secure certificates from both CSM servers according to the procedure detailed in 2.7.2, “Creating the truststore file for CSM installed on the DS8000 HMC” on page 28.

Note: You can use any existing LDAP user ID for authentication service. However, it is best to use the same CSM bind user ID as defined in 2.6.1, “Configuring LDAP using CSM GUI” on page 20.

For example, if you used CN=csmldapuser,CN=Users,DC=itso,DC=ibm,DC=com for the CSM LDAP configuration bind user ID, for the authentication service client user ID, use csmldapuser.


6. In the Truststore file information page (Figure 2-30), enter the required information:

– For Truststore File Location, click Browse and select your truststore file where the CSM secure certificates are stored in. See 2.7, “Creating or exporting the CSM truststore file” on page 25 if you need to get additional details about the truststore file.

– For Truststore File Password:

• If you got your truststore file by following the instructions on 2.7.1, “Getting the truststore for CSM stand-alone servers” on page 25, the password is passw0rd (with a zero instead of the letter O).

• If you created the truststore file by following the instructions on 2.7.2, “Creating the truststore file for CSM installed on the DS8000 HMC” on page 28, enter the password that was defined when the truststore was created.

– For Confirm Truststore File Password, enter the password again.

Click Next.

Figure 2-30 Truststore file information page


7. In the Map External Users and User Groups to DS8000 User Roles window (Figure 2-31), provide the required information:

a. For External Entity Name, enter the name of the user ID or group ID that exists in the LDAP directory that you want to grant access to the DS8000.

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 68).

d. Select the existing Copy Services Scope that you want to associate to the external entity name.

e. Click the Add button.

f. To map more than one user or group, repeat the steps. For detailed information about user groups and roles, see 3.1, “DS8000 roles and authorization levels” on page 68.

g. Click Next when you have completed all the maps that you need.

.

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

CSM limitation: At the time of writing (latest CSM release was 6.2.0.2), the use of nested LDAP groups (one group inside another group) is not supported. If you want to use LDAP groups, make sure that only one level of groups is used. For example, inside of a LDAP group called DS8000_CSMUsers you have only the usersids of LDAP users that you want to use for the DS8000 authentication and there is no additional LDAP groups inside of the DS8000_CSMUsers group.

Important: if there are copy services scopes defined on the DS8000 system, make sure that all external entities mapped to the user roles Administrator and Security Administrator have all scopes associated to them. The start key character ‘*’ is used to inform all scopes.


8. In the next window, review the configuration and select Back to make changes if necessary, or Next to continue (Figure 2-32).

Figure 2-32 Authentication service policy configuration review

9. In the Summary window (Figure 2-33), leave the Activate the Policy check box clear.

Click Finish to create the policy. Notice that, in the next step, we test the policy before activating it.

Figure 2-33 Summary page


Testing the remote Storage Authentication Service policyTo test the SAS policy, complete these steps:

1. In the Manage Authorization Policy window (Figure 2-34), select the authentication policy that you want to test. Under the Action menu, click Test Authentication Policy.

Figure 2-34 Test Authentication Policy

2. In the Test Storage Authentication Service Policy window (Figure 2-35), enter the values for the External User Name and External User Password fields and click OK to start the test. The user must be an existing user from the LDAP Directory that was mapped to a DS8000 user role in the previous steps.

Figure 2-35 Test policy


The test takes a few seconds to complete. When it is finished, the Test summary window is displayed. If the test was successful, the Result State box is displayed and closed shortly afterward unless the View Details button was selected. See Figure 2-36.

If something is wrong, the results page points to a possible cause of failure. In case of failure, go back to the configuration and check the settings, including the user IDs and passwords, and check that the LDAP server is running.

Figure 2-36 Test completes successfully

3. Click Close to return to the Manage Authentication Policy window.

Activating the remote Storage Authentication Service policyWhen a remote SAS policy is enabled, all the existing local users can no longer be authenticated. They remain in the DS8000 local registry, but they cannot be used until the default local SAS policy becomes enabled again.

Important: Although all the existing users will be disabled for login while the remote SAS policy is enabled, you need to make note of the credentials of local users with Administrator role. In particular, be sure to note the local credentials from the default admin user ID. If you want to disable the LDAP authentication policy for some reason, you will have to provide the valid credentials for a local DS8000 admin user to re-enable the local SAS policy. If you do not have those credentials, you will need to call IBM and allow an IBM remote support team individual to connect to your system to reset the credentials for the default admin user. This process can take some time and you will not be able to connect to the DS8000 system until the reset has been performed.

Starting with code bundle 87.50.114.0, it is possible to allow a local administrator to access the system when a remote authentication policy is configured and the external LDAP servers are inaccessible. For the code levels prior to R8.1 (88.10.x.x), that capability only could be configured using DSCLI. For code levels higher than R8.1 that functionality is also available in DSGUI.


If you are using a code level from R7.5 (87.50.114.x) and lower than R8.1 (88.10.x.x) and want to define a DS8000 local administrator user ID as a contingency for access when LDAP servers are inaccessible, you can use the DSCLI command “setauthpol -action setlocaladmin”, as detailed in Example 2-23 on page 62.

To active a SAS policy, complete the following steps:

1. In DSGUI, select the SAS policy that you want to activate. Under the Action menu, click Activate Authentication Policy (Figure 2-37).

Figure 2-37 Option for activate a SAS policy

Note: Before you activate the SAS policy, if you want to map any LDAP user ID or group ID to the Security Administrator role, complete the steps detailed under 2.9.4, “Mapping LDAP users and groups to DS8000 Security Administrator role” on page 64.


2. In the Activate Storage Authentication Service Policy window (Figure 2-38), provide the necessary information:

– For External User Name, enter a user ID that exists and is valid on the LDAP directory. That user ID must have a valid map associating it or its LDAP group to the DS8000 Administrator role.

– Enter the External User Password for the LDAP user ID used to enable the SAS policy.

Click OK to activate the policy.

Figure 2-38 Providing the LDAP credentials for active the SAS policy

3. The activation takes a few seconds to complete. If the activation was successful, the Result State box is displayed and closed shortly afterward unless the View Details button is selected, in which case the task properties is shown (Figure 2-39).

If something is wrong, the results page points to a possible cause of the failure.

Figure 2-39 Task properties result for a successful SAS policy activation


If the activation was successful, you get the Active status on the Policy State column (Figure 2-40).

Figure 2-40 Remote policy CSM_LDAP_Policy is active

4. You will not be disconnected from the DSGUI automatically. You must click Logout (Figure 2-41).

Figure 2-41 Logout option

5. You can now log on to DSGUI using any LDAP user ID if you did the correct mapping association during the remote policy configuration.

6. If you need to add new mappings to DS8000 roles, complete the steps provided in 3.1, “DS8000 roles and authorization levels” on page 68.

Disabling the remote Storage Authentication Service policyComplete these steps to disable the remote SAS policy and re-enable DS8000 local authentication:

1. Log on to the DSGUI using an external LDAP user that has DS8000 Administrator privileges or use the local DS8000 administrator user ID that you have configured as contingency. A contingency ID is set using the DSCLI command setauthpol -action setlocaladmin, and is available only for systems starting with code level Release 7.5, bundle 87.50.114.x.

2. Open the Manage Authentication Policy window.


3. In the Policy Name column, select initialPolicy, which is the default DS8000 local authentication policy (Figure 2-42).

Figure 2-42 The default initialPolicy used for DS8000 local authentication

4. From the Action menu, select Activate Authentication Policy (Figure 2-43).

Figure 2-43 Option for activate the initialPolicy


5. In the Activate Basic Authentication Policy window (Figure 2-44), provide the credentials of a locally defined DS8000 user with DS8000 Administrator role, which is why you needed to take note of valid credentials for a local DS8000 administrator user that existed before the remote authentication policy was activated.

Click OK and wait a few seconds to get the policy activated. If the activation process fails, a new window containing details about the error is shown to help with troubleshooting.

Figure 2-44 Activating the basic authentication policy

2.9.2 Using DSGUI on code levels at R8.1 (88.10.x.x) or higher

Use the following steps to configure the DS8000 LDAP authentication on systems with code level starting at Release 8.1 (Machine code 88.10.x.x):

1. Open the DSGUI (https://DS8000_HMC_IP:8452) and log on with an administrative user ID and password, and then click Log in (Figure 2-45)

Figure 2-45 DS8000 Storage Management login page


2. From the left icon menu, select Settings → Security (Figure 2-46)

Figure 2-46 Security settings

3. Select Remote Authentication and click Enable Remote Authentication (Figure 2-47).

Figure 2-47 Remote authentication option

4. The Welcome page of the Remote Authentication wizard opens. You can click Prerequisites to display and review the prerequisites for enabling the remote authentication. (Figure 2-48).

Figure 2-48 Prerequisites for enabling the remote authentication


5. Click Next to open the Authentication Servers tab to enter the Authentication Servers, as shown in Figure 2-49.

Figure 2-49 Authentication Servers configuration

Enter the following information:

– For Server Host Name, you can add up to two authentication servers that DS8000 will use for LDAP authentication. The Uniform Resource Identifier (URI) for each authentication server should be provided. Which URI to use depends on where the CSM server is installed:

• If the CSM server is installed on a stand-alone server, use this URI:


Example:


• If the CSM server is installed on the DS8000 HMC, use this URI:


Example:


Note: How the DS8000 accesses the CSM servers for requesting LDAP authentication must be configured according to where the CSM is installed:

� For CSM installations on a stand-alone server, the DS8000 must connect to port 9562 on the CSM server.

� For CSM installations on a DS8000 HMC, port 443 must be used by DS8000 after the port 9562 is blocked by the internal HMC firewall for connections coming from the customer network (interface eth2 on the HMC).


– For Truststore File click the Folder icon to select the truststore file where the CSM secure certificates are stored. See 2.7, “Creating or exporting the CSM truststore file” on page 25 if you need additional details about the truststore file.

– For Truststore Password:

• If you created your truststore file following the instructions in 2.7.1, “Getting the truststore for CSM stand-alone servers” on page 25, the password to be used is passw0rd (with a zero instead of the letter O).

• If you created the truststore file following the instructions on 2.7.2, “Creating the truststore file for CSM installed on the DS8000 HMC” on page 28, enter the password that was defined when the truststore was created.

– For WebSphere User Name, enter an existing LDAP user ID to be used by the DS8000 to authenticate on the CSM servers.

– For WebSphere Password, enter the password defined to the WebSphere User Name (in examples used by this book, it is the password for the LDAP user ID csmldapuser).

Important: If one of your CSM servers is installed on a stand-alone server and the other is installed on HMC, you need to use the correct URI for each them.

Example:

� URI for the primary CSM (a stand-alone server):


� URI for the secondary CSM (installed on HMC):


The only requirement for this configuration is that you need to create the Java truststore file containing the secure certificates from both CSM servers. Use the procedure detailed in the 2.7.2, “Creating the truststore file for CSM installed on the DS8000 HMC” on page 28.

Note: You can use any existing LDAP user ID for authentication service. However, generally use the same CSM bind user ID defined in 2.6.1, “Configuring LDAP using CSM GUI” on page 20. For example, if during the CSM LDAP configuration you have used as bind user ID CN=csmldapuser,CN=Users,DC=itso,DC=ibm,DC=com, for WebSphere User Name, use the user ID csmldapuser.


Figure 2-50 shows an example of configuration where two stand-alone CSM servers are used for LDAP authentication.

Figure 2-50 Example of configuration using two stand-alone CSM servers for authentication

6. Click Next to display the Authentication Mappings page (Figure 2-51). You need to assign DS8000 roles to the LDAP remote users or groups that you want to grant access to log in on DS8000.

Click Add Remote Mapping to create authentication mapping and to select the DS8000 role that you want to map.

Figure 2-51 Authentication Mappings page


7. In the Create Authentication Mapping page (Figure 2-52), complete these fields:

a. From the available role list, select the DS8000 user role to be mapped. See Table 3-1 on page 68 if you need detailed information about each DS8000 user role.

b. For Mapping Type, select the LDAP object type (User or User Group) that you want to use for mapping to a DS8000 role.

c. For User Name or Group Name, enter the name of user ID or group ID that exists in the LDAP directory and for which you want to grant access to the DS8000.

d. Click the Add button. To add new mappings, repeat the steps from this section. For detailed information about user groups and roles, see 3.1, “DS8000 roles and authorization levels” on page 68.

Figure 2-52 Creating an authentication mapping

Note: The Security Administrator role can only be managed by a DS8000 user that already belongs to that role (such as the default user secadmin). Additional details about how to map an LDAP user to the Security Administrator role can be found in 2.9.4, “Mapping LDAP users and groups to DS8000 Security Administrator role” on page 64.

CSM limitation: At the time of writing (latest CSM release was 6.2.0.2), the use of nested LDAP groups (one group inside another group) is not supported. If you want to use LDAP groups, make sure that only one level of groups is used. For example, inside of an LDAP group called DS8000_CSMUsers, you have only the user IDs of LDAP users that you want to use for the DS8000 authentication, and there are no additional LDAP groups inside the DS8000_CSMUsers group.


8. Click Next when you have completed all the mappings that you need (Figure 2-53).

Figure 2-53 Example of an authentication mapping

9. On the Local Administrator page (Figure 2-54), you can define an existing DS8000 local administrator that will remain active for recovery purposes if the remote authentication servers (LDAP, CSM, or both) are not available.

Select the Allow check box to enable the local administrator feature. Then, select one of the existing DS8000 local users with the administrator role to be used as recovery user. The current password configured for the local user you have selected will be used. Therefore, make sure that the correct password is configured before proceeding to the next steps. After the remote authentication is enabled, you will not be able to change the password for the recovery user.

Assigning an administrator role helps to avoid a situation where you activate remote authentication with an LDAP server with no defined mapping for an administrator account. If you activated remote authentication without a defined mapped administrator and then log out, you cannot log back in to add new remote authentication mappings.

.

Figure 2-54 Enabling the local default DS8000 user “admin” to be used for recovery

Note: Generally, use the default local DS8000 admin user as the recovery user ID (Local Administrator). Also, take note of the password.


If you need to disable the remote authentication on the remote LDAP/CSM servers, you must log in using the valid credentials of the recovery user. If you do not have these credentials, to call IBM and request that a person from the remote IBM support team connect to your system and reset the credentials for the default admin user. This process can take some time and you will not be able to connect to the DS8000 system until the reset is performed remotely.

10.Click Next to display the Administrator Verification page.

11.During the remote authentication activation, the DS8000 tries to authenticate with LDAP server one using the LDAP users that you have previously mapped to the Administrator role (step 7 on page 61) to validate that configuration is working. In the Administrator Verification page (Figure 2-55), you must specify one of the LDAP users that you have mapped as DS8000 administrator and provide its LDAP credentials.

If the LDAP user name you have provided was not previously mapped to the DS8000 Administrator role or the provided password for it is not correct, the remote authentication activation fails.

Figure 2-55 LDAP user mapped to the DS8000 Administrator role to be used for verification

12.Click Next to display the Summary page. Review all of the selections (Figure 2-56) before you finalize the remote authentication setup. Select Back to make changes, if necessary. Otherwise, click Finish to enable the remote authentication.

Figure 2-56 Configuration summary for the remote authentication


If the remote authentication was successfully enabled, you will get the status Task completed and DSGUI will automatically disconnect your session, indicating that the Authentication Policy Changed (Figure 2-57). The default internal name for the remote authentication policy created by DSGUI is GUIRemotePolicy.

You can now log in to DSGUI using any LDAP user ID that you have mapped during the remote policy configuration.

If you need add new mappings to DS8000 roles, use the steps provided on 3.1, “DS8000 roles and authorization levels” on page 68.

Figure 2-57 Message received when the remote authentication is successfully enabled

Enabling, disabling, and modifying the Local Administrator (recovery ID)If you did not enable the recovery/contingency ID using the Local Administrator feature when the remote authentication was configured and you want to enable it now, you can use the DSGUI or DSCLI without causing any impact to your remote authentication.

You can also disable the Local Administrator feature or change the currently configured local user by simply choosing any other available DS8000 local administrator user. However, keep in mind that you will not able to create any new local user if the remote authentication is enabled. In other words, you can only select local users that were created before the remote authentication is enabled.


To perform changes on the Local Administrator feature while the remote authentication is enabled, complete these steps:

1. Log in to the DSGUI (https://DS8000_HMC_IP:8452) using an external LDAP user that has DS8000 Administrator privileges.

2. Select Settings → Security → Remote Authentication and move to the Local Administrator section. The available options depend on the status of the Local Administrator feature:

– If the Local Administrator feature currently is disabled, you can enable it by clicking Enable (Figure 2-58). You are prompted to select an existing DS8000 local administrator user.

Figure 2-58 Option for enabling the Local Administrator feature

– If the Local Administrator feature is enabled, you can disable it or modify the DS8000 local admin user that is being used (Figure 2-59).

Figure 2-59 Options for disabling and modifying the Local Administrator feature


Using the “new DSGUI” to disable Remote Authentication To disable remote authentication and re-enable the DS8000 local authentication, complete these steps:

1. Log in to the DSGUI (https://DS8000_HMC_IP:8452) using an external LDAP user that has DS8000 Administrator privileges or use the local DS8000 administrator user ID that you have configured as contingency/recovery. Select Settings → Security → Remote Authentication (Figure 2-60).

Figure 2-60 Enabled Remote Authentication

2. For Remote Authentication, select Disabled and provide the credentials of any existing DS8000 local administrator user (it can be the recovery/contingency user name itself or any previous local administrator for which you know the credentials).

Click Enable to enable back the DS8000 local authentication (Figure 2-61).

Figure 2-61 Providing the credentials to enable the DS8000 local authentication


3. Click Yes to confirm that you want to enable the DS8000 local authentication and disconnect any user currently logged in using the remote authentication (Figure 2-62).

Figure 2-62 Warning message while enabling the DS8000 local authentication

4. If the remote authentication is successfully enabled, you see the status Task completed and DSGUI automatically disconnects your session with the reason Authentication Policy Changed (Figure 2-63).

Figure 2-63 Concluding the tasks for enabling the DS8000 local authentication

You can now log in to DSGUI using any valid DS8000 local user.

2.9.3 Configuring DS8000 LDAP authentication by using the DS CLI

Rather than using the DSGUI, you can configure the DS8000 external authentication policy through the DSCLI by completing the following steps:

1. Open the DSCLI command window and connect to your DS8000 system using the credentials from a local DS8000 administrator user (such as the default admin user ID).

2. To see the existing authentication policies, enter the lsauthpol command, as shown in Example 2-16. As you can see, the default initialPolicy is set to Basic (local authentication).

Example 2-16 Listing Authentication policies

dscli> lsauthpolDate/Time: November 18, 2017 5:05:03 PM MST IBM DSCLI Version: 7.8.24.11 DS: -name type state==========================initialPolicy Basic active


3. Create a new empty policy. Where the -type sas specifies the authentication policy type, enter the mkauthpol -type sas itsopolicy command that is shown in Example 2-17. Currently, Storage Authentication Service (SAS) is the only valid value for this parameter, and it is required. Also, itsopolicy defines the name from the new policy.

Example 2-17 Creating a policy

dscli> mkauthpol -type sas itsopolicyDate/Time: November 18, 2017 5:07:08 PM MST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00365I mkauthpol: The authentication policy itsopolicy has been created.

4. Use the lsauthpol command to confirm that itsopolicy was correctly created (Example 2-18).

Example 2-18 Listing of the available policies

dscli> lsauthpolDate/Time: November 18, 2017 5:08:13 PM MST IBM DSCLI Version: 7.8.24.11 DS: -name type state============================initialPolicy Basic activeitsopolicy SAS inactive

5. Add the authentication servers to the policy itsopolicy, as shown in Example 2-19. Enter the setauthpol command with the -action setauthserver and -loc parameters, where the -loc contains the URI for the CSM servers. In this example, we are adding two CSM stand-alone servers.

Example 2-19 Setting the CSM authentication servers

dscli> setauthpol -action setauthserver -loc https://csm01.itso.ibm.com:9562/CSMAuth/TokenService,https://csm02.itso.ibm.com:9562/CSMAuth/TokenService itsopolicyDate/Time: November 18, 2017 5:13:56 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

For the -loc parameter, you can add up to two authentication servers that DS8000 will request for LDAP authentication. The URI for each authentication server should be provided. Which URI to use will depend on where your CSM server is installed:

– If the CSM server is installed on a stand-alone server, use the following URI:


Example:


– If the CSM server is installed on the DS8000 HMC, use the URI:


Example:



6. Add the keystore file to the itsopolicy 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 “Creating or exporting the CSM truststore file” on page 25). Use the -pw parameter for the truststore file password. See Example 2-20.

Example 2-20 Setting the key

dscli> setauthpol -action settruststore -loc c:\key_itso.jks -pw passw0rd itsopolicyDate/Time: November 18, 2017 5:16:20 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

7. Enter with the credentials of an existing LDAP user to be used by the DS8000 to authenticate with the CSM servers by using the setauthpol command with -action setsasuser parameter, as shown in Example 2-21. In this example, we are using an LDAP user called csmldapuser (password LDAP$3cret).

Example 2-21 Setting the ESS user

dscli> setauthpol -action setsasuser -username csmldapuser -pw LDAP$3cret itsopolicDate/Time: November 18, 2017 5:40:13 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

Important: If one of your CSM servers is installed on a stand-alone server and the one is installed on the HMC, you need to use the corresponding URI.

Example:

� URI for the primary CSM (a stand-alone server):


� URI for the secondary CSM (installed on HMC):


The only requirement for this configuration is that you need to create the Java truststore file containing the secure certificates from both CSM servers according to the procedure detailed in 2.7.2, “Creating the truststore file for CSM installed on the DS8000 HMC” on page 28.

Note: Although you can use any existing LDAP user ID for authentication, generally use the same CSM bind user ID defined in 2.6.1, “Configuring LDAP using CSM GUI” on page 20.

For example, if during the CSM LDAP configuration you have used as bind user ID CN=csmldapuser,CN=Users,DC=itso,DC=ibm,DC=com, then use csmldapuser for the WebSphere User Name.


8. Map existing users and user groups from the LDAP server to user groups on the DS8000 by entering the setauthpol -action setmap command with the -extuser or -extgroup parameters associated to the specific DS8000 groups (parameter -dsgroup), as shown in Example 2-22.

Example 2-22 Mapping a user to a group

dscli> setauthpol -action setmap -extuser lopesle,omarhass -dsgroup admin itsopolicyDate/Time: November 18, 2017 5:50:55 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

dscli> setauthpol -action setmap -extgroup ldapmonitors -dsgroup monitor itsopolicyDate/Time: November 18, 2017 5:51:03 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

In Example 2-22, we are adding three mappings:

– The LDAP users lopesle and omarhass are being mapped to the DS8000 Administrator role.

– All the LDAP users that belong to the LDAP group ldapmonitors are being mapped to the DS8000 Monitor role.

For detailed information about user groups and roles, see 3.4, “Managing user mappings by DSCLI” on page 74.

9. Starting with code bundle 87.50.114.0, you can allow a local administrator to access the system when a remote authentication policy is configured and the external LDAP servers are inaccessible. If your code bundle supports this feature, use the setauthpol command with -action setlocaladmin parameter, as shown in Example 2-23.

In this example, the default DS8000 local user admin is being configured as the recovery ID.

Example 2-23 Setting the contingency/recovery ID

dscli> setauthpol -action setlocaladmin -username admin -enable itsopolicyDate/Time: November 18, 2017 6:02:16 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

10.Now t the policy is set up but still in inactive state, as shown in Example 2-24.

Example 2-24 Showing the details about the itsopolicy

dscli> showauthpol itsopolicyDate/Time: November 18, 2017 6:16:19 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -name itsopolicytype SASstate inactivelocation https://csm01.itso.ibm.com:9562/CSMAuth/TokenService,https://csm02.itso.ibm.com:9562/CSMAuth/TokenServicetruststore itsopolicy_trustStore.jkssasuser csmldapuserlocalAdmin admin


11.Test the configuration by entering the testauthpol command and the credentials from one of the LDAP users that you have mapped as DS8000 administrator in the previous steps, as shown in Example 2-25.

Example 2-25 Testing the configuration

dscli> testauthpol -username lopesle -pw MySecur3Pas$ itsopolicyDate/Time: November 18, 2017 6:19:50 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00371I testauthpol: The authentication policy itsopolicy has been authenticated on location https://csm01.itso.ibm.com:9562/CSMAuth/TokenService.CMUC00371I testauthpol: The authentication policy itsopolicy has been authenticated on location https://csm02.itso.ibm.com:9562/CSMAuth/TokenService.

12.If the test completed successfully, you can activate the policy by entering the chauthpol command with the -activate parameter and the credentials from one of the LDAP users that you have mapped as DS8000 administrator as shown in Example 2-26.

Keep in mind that the basic authentication will be inactive and you will get a command execution time-out message after some time (about 5 minutes). That is expected, and you need to logoff from DSCLI and reconnect using the LDAP credentials.

Example 2-26 Activating the itsopolicy

dscli> chauthpol -activate -username lopesle -pw MySecur3Pas$ itsopolicyDate/Time: November 18, 2017 6:35:47 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00370W chauthpol: Are you sure that you want to modify the authentication policy itsopolicy? [y/n]:yCMUN00015E chauthpol: Command execution timeout

13.Connect again to the DSCLI by using an LDAP user with administrator role and check the state for the policy by entering the lsauthpol command (Example 2-27).

Example 2-27 Listing of the available policies

ddscli> lsauthpolDate/Time: November 18, 2017 6:43:53 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -name type state============================initialPolicy Basic inactiveitsopolicy SAS active

Disabling the remote authentication policy using DSCLIUse the following procedure to disable a remote authentication policy using DSCLI:

1. Open the DSCLI command window and connect to your DS8000 system using the credentials from a DS8000 administrator user (or the recovery ID - Local Administrator feature).

2. To see the existing authentication policies, enter the lsauthpol command, as shown in Example 2-28. On this example, the remote authentication policy GUIRemotePolicy is active (enabled) and the local authentication policy initialPolicy is inactive (disabled).

Example 2-28 Listing Authentication policies

dscli> lsauthpolDate/Time: November 19, 2017 7:04:37 AM BRST IBM DSCLI Version: 7.8.24.11 DS: -name type state


==============================GUIRemotePolicy SAS activeinitialPolicy Basic inactive

3. The way for disabling a remote authentication policy is enabling the local authentication (the basic initialPolicy). Enter the chauthpol command with the -activate parameter for the initialPolicy and provide the credentials from one DS8000 local administrator user as shown in Example 2-29. Keep in mind that all remote users who are currently logged in will be logged out.

Example 2-29 Enabling the local authentication policy

dscli> chauthpol -activate -username admin -pw Adm1nP4S$ initialPolicyDate/Time: November 19, 2017 7:19:06 AM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00370W chauthpol: Are you sure that you want to modify the authentication policy initialPolicy? [y/n]:yCMUC00369I chauthpol: The authentication policy initialPolicy has been modified.

dscli> lsauthpolDate/Time: November 19, 2017 7:19:19 AM BRST IBM DSCLI Version: 7.8.24.11 DS: -name type state==============================GUIRemotePolicy SAS inactiveinitialPolicy Basic active

2.9.4 Mapping LDAP users and groups to DS8000 Security Administrator role

The DS8000 offers a self-encrypting disk solution that uses IBM Full Disk Encryption (FDE) disks and flexible key manager software.

If your DS8000 is configured for secure data at rest using encryption, during the initial setup a recovery key had to be created. The DS8000 offers a recovery key to get access to data if none of the key servers are available.

To prevent one person from gaining access to the data, the handling of a recovery key requires two people (separate roles): A security administrator (secadmin) and a storage administrator (admin).

Additional details about encryption on DS8000 are available in IBM DS8880 Data-at-rest Encryption, REDP-4500.

The following rules apply:

� Any user that has Security Administrator authority cannot have the authority of any other user role, and a user with any other user role cannot have the Security Administrator authority at the same time.

� The secadmin user can only create new users with Security Administrator authority.

� Unlike secadmin user, the admin user can create users with all authorities except the Security Administrator role.

� Only a user that has Storage Administrator authority is able to create, enable, and disable a DS8000 remote authentication policy.


� Any user that has Security Administrator authority is able to modify a previously created remote authentication policy. However, they are only able to map LDAP users or groups to the Security Administrator role (no additional roles are allowed).

� Except for the Security Administrator role, all the remaining roles can be mapped to LDAP users or groups by any user that has Storage Administrator authority.

To create any LDAP user or group mapping to the Security Administrator role in a remote authentication policy, you must fulfill the following requirements:

� A remote authentication policy must already exist (previously created by a Storage Administrator user) and it must be disabled. If the remote authentication policy is enabled, log in from DS8000 local users (example: secadmin) will not be allowed.

� Any user that has the Security Administrator authority must to use the DSCLI tool to perform the mapping configuration.

Complete the following steps to create any LDAP user or group mapping to the Security Administrator role:

1. Make sure that remote authentication policy is disabled (inactive) as shown in Example 2-30. If it is not enabled, any user with Storage Administrator authority must disable it using the steps detailed in “Disabling the remote Storage Authentication Service policy” on page 46, “Using the “new DSGUI” to disable Remote Authentication” on page 58, and “Disabling the remote authentication policy using DSCLI” on page 63.

2. Open the DSCLI command window and connect to your DS8000 system by using the credentials from a local DS8000 security administrator user (example: the default secadmin user ID).

3. To see the existing authentication policies, enter the lsauthpol command, as shown in Example 2-30. In this example, the only available remote authentication policy GUIRemotePolicy is inactive (disabled).

Example 2-30 Listing the available authentication policies

dscli> lsauthpolDate/Time: November 19, 2017 7:27:15 AM BRST IBM DSCLI Version: 7.8.24.11 DS: -name type state==============================GUIRemotePolicy SAS inactiveinitialPolicy Basic active

4. Map any existing users and user groups from the LDAP server to the DS8000 Security Administrator group by entering the setauthpol -action setmap command with the -extuser or -extgroup parameters, as shown in Example 2-31.

In this example, the LDAP user ldapsecadminuser is being associated to the DS8000 Security Administrator role.

Example 2-31 Mapping an LDAP user to the DS8000 Security Administrator group

dscli> setauthpol -action setmap -extuser ldapsecadminuser -dsgroup secadmin GUIRemotePolicyDate/Time: November 19, 2017 7:36:49 AM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00366I setauthpol: The authentication policy GUIRemotePolicy has been modified.


5. If you need to create any additional mapping to the DS8000 Security Administrator role, repeat step 4. When you have create all the mappings that you need, disconnect from the DSCLI.

6. Inform your DS8000 Storage Administrator that remote authentication policy was changed and it can be activated. As soon as the storage administrator activates the remote authentication policy, all the LDAP users that were mapped in step 4 will be able to log in to DS8000.


Chapter 3. User, group, and role mapping

This chapter explains how to map IBM DS8000 users and roles with Lightweight Directory Access Protocol (LDAP) users and groups.


� DS8000 roles and authorization levels� Managing user mappings in DSGUI with code levels older than R8.1� Managing user mappings by DSGUI on code levels higher than R8.1� Managing user mappings by DSCLI

3


3.1 DS8000 roles and authorization levels

Using DS8000 remote authentication, users and groups from LDAP are associated with predefined DS8000 roles. When a user ID is authenticated to a DS8000 through the graphical user interface (DSGUI) or command line interface (DSCLI), the user’s membership in a particular LDAP group determines the user’s authorization level. Table 3-1 shows the association between each DS8000 role and their authorization level.

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 (view, create, delete) to all service functions and DS8000 resources.

Security Administrator

This user role allows users to initiate recovery key operations, and add other users to this role. Users in this role may not be assigned to any other role, and users in any other role may not be assigned to this role.

Logical operator This role has access (view, create, delete) 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

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

Logical operator and Copy Services operator

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.


3.2 Managing user mappings in DSGUI with code levels older than R8.1

To manage the mappings on a remote authentication policy, complete these steps:

1. Open the DSGUI by using an administrative user ID and password, and then click Login.

2. Select Remote Authentication in the Access” menu from the lock icon, as shown in Figure 3-1.

Figure 3-1 Remote Authentication access

3. In the Remote Authentication page, select the Complex Name related to your DS8000 and from the Action menu, select Manage Authentication Policy, as shown in Figure 3-2.

Figure 3-2 Selecting the SAS policy for managing the user mappings

Note:

� For DS8700 and DS8800, the DSGUI can be accessed from a web browser using this address:


� For DS8870 and DS888x R8.0 (from 88.0.x.x to 88.1.x.x), the previous DSGUI can still be accessed from a web browser using this address:


Chapter 3. User, group, and role mapping 69


https://ds8000HMCIP:8452


4. In the Manage Authorization Policy page (Figure 3-3), select the authentication policy that you want to manage the user mappings. Under the Action menu, select Properties.

Figure 3-3 Accessing the properties from a SAS policy

5. In the Storage Authentication Service Policy Properties page (Figure 3-4), click the External Users tab.

Figure 3-4 External Users mapping


3.2.1 Adding a user mapping

To add a user mapping, access the External Users tab on the Storage Authentication Service Policy Properties page, as shown in Figure 3-4 on page 70, and proceed as follows:

1. For External Entity Name, enter the name of the user ID or group ID that exists in the LDAP directory for which you want to grant access to the DS8000.

2. Select the External Entity Type. The type of entity can be External User Group or External User Name.

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

4. Select the existing Copy Services scope that you want to associate to the external entity name.

5. Click Add.

6. Repeat the previous steps (1-5) to add additional mappings.

7. After you have added all the mappings that you want, click OK.

3.2.2 Removing a user mapping

To remove an existing user mapping, access the External Users tab on the Storage Authentication Service Policy Properties page, as shown in Figure 3-4 on page 70, and proceed as follows:

1. At the bottom table containing the existing user mappings, select the External Entity Name related to the LDAP user for which you want to remove access.

2. From the Action menu, select Remove and make sure that LDAP user was removed from the table.

3. Repeat the previous steps to remove any other existing mappings.

4. After you have removed all the mappings that you want, click OK.

3.2.3 Modifying a user mapping

If you need to modify any user mapping that is already defined, remove the current user mapping using the instructions provided in 3.2.2, “Removing a user mapping” on page 71. After the user mapping is removed, you can create it again using the correct attributes that you need as described in 3.2.1, “Adding a user mapping” on page 71.


3.3 Managing user mappings by DSGUI on code levels higher than R8.1

To manage the mappings on a remote authentication policy:

1. Open the DSGUI (https://DS8000_HMC_IP:8452) by using an administrative user ID and password, and then click Login.

2. On the left menu, select Settings → Security (Figure 3-5)

Figure 3-5 Security settings

3. Select Remote Authentication and click the Remote Authentication Mappings section (Figure 3-6).

Figure 3-6 Remote authentication mappings


3.3.1 Adding a new user mapping

To add a new user mapping, access the Remote Authentication section as shown in Figure 3-6 and proceed as follows:

1. Click Add Remote Mapping.

2. In the Create Authentication Mapping page (Figure 3-7), complete these fields:

– From the available role list, select the DS8000 user role to be mapped (see Table 3-1 on page 68 if you need detailed information about each DS8000 user role).

– For Mapping Type, select the LDAP object type (User or User Group) that you want to use for mapping to a DS8000 role.

– For User Name or Group Name, enter the name of user ID or group ID that exists in the LDAP directory and for which you grant access to the DS8000.

Figure 3-7 Creating an authentication mapping

3. Click Add. To add more mappings, just repeat the steps.


To remove an existing user mapping, access the Remote Authentication section, as shown in Figure 3-6 on page 72, and proceed as follows:

1. In the bottom table containing the existing user mappings, select the Remote User related to the LDAP user for which you want to remove the access.

2. From the Action menu, select Remove.

3. Repeat the previous steps to remove any other existing mappings.



To modify an existing user mapping, access the Remote Authentication section, as shown in Figure 3-6 on page 72, and proceed as follows:

1. In the bottom table containing the existing user mappings, select the Remote User related to the LDAP user for which you want to remove the access.

2. From the Action menu, click Modify.

3. On the Modify Authentication Mapping page (Figure 3-8), complete all changes that you need and click Modify to save the configuration:

Figure 3-8 Modifying an existing user mapping

4. Repeat the previous steps to modify any other existing mappings.

3.4 Managing user mappings by DSCLI

The DS8000 authority group roles for the DSCLI (see Table 3-1 on page 68) have the following possible values:

� admin� op_storage� op_volume� op_copy_services� service� monitor� no_access

The DSCLI command that is used to manage the user mappings on a remote authentication policy is setauthpol.


3.4.1 Adding a user mapping

You can use the following DSCLI commands to add a new user mapping on a remote authentication policy:

� For an LDAP user mapping:

setauthpol -action addmap -extuser <LDAPUser> -dsgroup <DS8K_Group> <policyName>

� For an LDAP group mapping:

setauthpol -action addmap -extgroup <LDAPGroup> -dsgroup <DS8K_Group> <policyName>

See Example 3-1 for an illustration.

Example 3-1 Adding a user mapping

dscli> setauthpol -action addmap -extuser jbranden -dsgroup admin GUIRemotePolicyDate/Time: November 19, 2017 7:33:46 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00366I setauthpol: The authentication policy GUIRemotePolicy has been modified.


You can use the following DSCLI commands to remove an existing user mapping from a remote authentication policy:


setauthpol -action rmmap -extuser <LDAPUser> -dsgroup <DS8K_Group> <policyName>


setauthpol -action rmmap -extgroup <LDAPGroup> -dsgroup <DS8K_Group> <policyName>

See Example 3-2 for an illustration

Example 3-2 Removing an existing user mapping

dscli> setauthpol -action rmmap -extuser omarhass -dsgroup admin GUIRemotePolicyDate/Time: November 19, 2017 7:36:57 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00366I setauthpol: The authentication policy GUIRemotePolicy has been modified.


You can use the following DSCLI commands to modify an existing user mapping on a remote authentication policy:


setauthpol -action setmap -extuser <LDAPUser> -dsgroup <DS8K_Group> <policyName>


setauthpol -action setmap -extgroup <LDAPGroup> -dsgroup <DS8K_Group> <policyName>


See Example 3-3 for an illustration

Example 3-3 Modifying a user mapping

dscli> setauthpol -action setmap -extgroup ldapmonitors -dsgroup op_storage GUIRemotePolicyDate/Time: November 19, 2017 7:30:09 PM BRST IBM DSCLI Version: 7.8.24.11 DS: -CMUC00366I setauthpol: The authentication policy GUIRemotePolicy has been modified.


Appendix A. Installing Copy Services Manager

This appendix explains how to install the IBM Copy Services Manager v6.2 on Windows Server 2012 R2.

In this installation, we mostly use the default values, which are suitable for most environments. It is important to note that the Copy Services Manager v6.2 installation wizard will only run once.

This appendix includes the following sections:

� Preparation steps� Install Copy Services Manager

A

Prerequisites: To install a Copy Services Manager v6.2 server on Windows Server 2012 R2, you must have the latest Windows Service Packs and Microsoft hot fixes installed. Make sure that you have the minimum requirements mentioned in the following link:

https://www.ibm.com/support/knowledgecenter/en/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/frc_c_install_overview.html

More information about the supported platforms can be found at the following link:




https://www.ibm.com/support/knowledgecenter/en/SSESK4_6.2.0/com.ibm.storage.csm.help.doc/frc_c_install_overview.html

A.1 Preparation steps

Before you start the Copy Services Manager installation, complete the following preparation steps:

1. Download the required package for the operating system.

2. Verify that the TCP/IP ports are available and unused. If you are running firewall software, make sure that appropriate ports are open.

3. Make sure to run any installation program as administrator and be sure to accept any User Account Control (UAC) controls request during installation.

4. Verify that the server is running the latest version of Microsoft Windows 2012 R2, with up-to-date patches.

5. Verify that the server’s host name is valid in the Windows hosts file. A fully qualified domain name (FQDN) is required in the hosts file before installing Copy Services Manager.

6. Make sure that the downloaded package is decompressed before proceeding with the installation. Extract the Storage_CSM_Setup_6.2.0_Win.zip file in the same directory.

7. Start the Copy Services Manager V6.2 installer.

8. When you are prompted to select a language for the installation (Figure A-1), select your language, and then click OK. This setting is the language for the installation wizard only. You will be prompted to select the language for Copy Services Manager later.

Figure A-1 Language selection

9. In the License Agreement window, accept the terms of the license agreement to continue with the installation and click Next.

Note: Copy Services Manager can be downloaded from the following link:


You can also download the Copy Service Manager from the Passport Advantage® website to gain access to the license file.


http://www.ibm.com/software/products/en/tivostorprodcent/


A.2 Install Copy Services Manager

Now, you are ready to install the Copy Services Manager. Complete these steps:

1. On the Introduction page (Figure A-2), click Next to select the Copy Services Manager license.

Figure A-2 Copy Services Manager: Introduction

2. Enter the path where the license.zip file exists (Figure A-3), and click Next.

Figure A-3 Copy Services Manager: Select License

Appendix A. Installing Copy Services Manager 79

3. Select the csm-license.zip file (Figure A-4).

Figure A-4 Selecting the csm-license.zip file

4. Click Open to see the license agreement and continue with the installation.

5. Read the license agreement and click Next after accepting the license agreement, as shown in Figure A-5.

Figure A-5 Accepting License Agreement


6. Select the installation method to be used (Figure A-6), either Install (for new CSM installation) or Migrate (for migration from TPC-R or restoring from CSM installation).

Click Next to continue.

Figure A-6 Selecting the installation method to use

7. Confirm the installation path for the Copy Services Manager (Figure A-7), and click Next.

Figure A-7 Copy Services Manager installation path

Appendix A. Installing Copy Services Manager 81

8. In the next window (Figure A-8), specify the Copy Services Manager user ID and password, and click Next.

Figure A-8 Creating Copy Services Manager user name and password

9. Review the installation summary, and click the Install button to continue.

After the Copy Services Manager installation completes, all tasks should be listed on the left side of the installer and marked with correct.

You can exit the Copy Services Manager installation by clicking Done.


Appendix B. Configuring Copy Services Manager for LDAP authentication using Microsoft Active Directory

This appendix explains how to enable LDAP on a Copy Services Manager 6.2 server. Make sure that you have the latest patches available for Copy Services Manager 6.2.

After you have the Copy Services Manager 6.2 server installed, you can configure it for Lightweight Directory Access Protocol (LDAP) authentication. That step must be completed before configuring the IBM DS8000 storage system for LDAP authentication.

This appendix includes the following section:

� Configuring Copy Services Manager for LDAP� Testing Copy Services Manager for LDAP

B


B.1 Configuring Copy Services Manager for LDAP

LDAP support can be enabled from the IBM Copy Services Manager GUI.

Follow these steps to configure the Copy Services Manager for authentication through LDAP:

1. Log in to the LDAP server with an administrative privilege account. In our test environment, we use administrator.

2. Open a Windows command prompt as administrator.

a. As illustrated in Figure B-1, issue the command dsquery user -name ldapuserid.

b. Make sure to take note of the values returned for the CN and DN parameters.

Figure B-1 Checking LDAP user Configuration.

3. Log in to the Copy Services Manager Server web GUI with administrative privilege.

4. Click Settings → Administration, as shown on Figure B-2.

Figure B-2 Accessing the Administration window

5. The Administration window is displayed. Click the Modify button (Figure B-3).

Figure B-3 Administration panel


6. The LDAP Configuration window is displayed. Select Active Directory and then click Add Authentication Server (Figure B-4).

Figure B-4 LDAP configuration window

7. In the Add Authentication Server window, enter the Active Directory Authentication Server IP address and Port (Figure B-5).

Figure B-5 Adding an authentication server

Note: By default, the non secured port is 389 and the secured port is 636. Select the appropriate value based on your Active Directory Server Configuration.

Appendix B. Configuring Copy Services Manager for LDAP authentication using Microsoft Active Directory 85

8. Complete the three remaining fields using the information collected in step 2 and click Test (Figure B-6).

Figure B-6 Testing access to the LDAP authentication server

9. The following message is displayed when the test completes successfully (Figure B-7). Click OK to close the message.

Figure B-7 LDAP server connectivity success

10.Click Save (Figure B-6) to save the current Active Directory configuration.

At this stage, Copy Service Manager is now configured for LDAP authentication.


B.2 Testing Copy Services Manager for LDAP

To make sure that CSM is able to talk to the configured LDAP servers, you can grant access to a user or group from LDAP on CSM.

Complete the following steps:

1. In the Administration window, click Add Access to start adding the users or groups that need access to Copy Services Manager (Figure B-8).

Figure B-8 Adding CSM users and groups for LDAP access

2. Enter the LDAP user or group name that you want to grant access to and click Next. (Figure B-9).

Figure B-9 Add user Welcome window

3. Select the user name that you want to use and click Next.

Note: You do not need to grant access to CSM server for LDAP users or groups if your only desire is use CSM for DS8000 authentication. The steps listed below just ensure that the communication between the CSM and LDAP servers is working as expected.


4. The Select Access Level window is displayed. Select the required Access Level and click Next (Figure B-10).

Figure B-10 Select Access Level

5. A confirmation message is displayed showing the user and the selected access level. Click Next to proceed (Figure B-11).

Figure B-11 Confirm user

6. In the next window, click Finish.

The user has been added and will now appear in the administration tab as shown in Figure B-12.

Figure B-12 User added


7. Log out of Copy Service Manager and log back in again, but this time with the LDAP user.

The configuration can be confirmed by checking the user name as shown in Figure B-13.

Figure B-13 Logged in as LDAP user


Appendix C. Exporting secure certificates in Google Chrome and Microsoft Internet Explorer

This appendix explains how to export a secure certificate using the Google Chrome and Microsoft Internet Explorer web browsers.

Exporting of the CSM secure certificate is one of the steps required to create the Java truststore file. This file is used during the configuration of remote authentication on DS8000 when at least one of the CSM servers is installed on DS8000 HMC. For more information, see the 2.7.2, “Creating the truststore file for CSM installed on the DS8000 HMC” on page 28.


� Certificate export on Microsoft Internet Explorer� Certificate export in Google Chrome

C


C.1 Certificate export on Microsoft Internet Explorer

Complete the following steps to export the CSM secure certificate using the web browser Microsoft Internet Explorer:

1. Open the Internet Explorer browser and connect to the CSM server using the correct URL for the secure certificate you want to export:

– For a CSM server installed on the DS8000 HMC:


– For a CSM server installed on a stand-alone server:

https://FQDN_or_IP_of_the_CSM_server:9562/CSM/

2. Regardless of the secure certificate URL you are using, click the certificate details to the right of the CSM URL and click View certificates (Figure C-1).

Figure C-1 Viewing the CSM secure certificate

3. In the Certificate window (Figure C-2), go to the Details tab and click Copy to File.

Figure C-2 Details of CSM auto-generated secure certificate


4. The Certificate Export wizard is started. Click Next (Figure C-3).

Figure C-3 Certificate Export wizard

5. In the Export File Format window, select Base-64 encoded X.509 (.CER) and click Next (Figure C-4).

Figure C-4 Export file format

Appendix C. Exporting secure certificates in Google Chrome and Microsoft Internet Explorer 93

6. In the File to Export window, select the folder where you want to save the exported certificate and provide a name for the file where the certificate will be saved. Click Next to continue (Figure C-5).

Figure C-5 File to export

7. The Completing the Certificate Export Wizard window shows a summary of your settings. Confirm that all information is correct and click Finish (Figure C-6).

Figure C-6 Summary of the certificate export wizard

8. You should receive confirmation that the export was successful. Click OK to conclude the process (Figure C-7).

Figure C-7 Conclusion of export process


C.2 Certificate export in Google Chrome

The following steps guide you to export the CSM secure certificate using the Google Chrome web browser:

1. Open the Google Chrome browser and connect to the CSM server using the correct URL for the secure certificate that you want to export:

– For a CSM server installed on the DS8000 HMC:


– For a CSM server installed on a stand-alone server:

https://FQDN_or_IP_of_the_CSM_server:9562/CSM/

2. Regardless of the secure certificate URL that you are using, click Customize and control Google Chrome indicated by the three vertical dots to the right of the CSM URL, and then select More tools → Developer tools (Figure C-8).

Figure C-8 Opening the Chrome Developer tools


3. In the Developer tools window, click Security → View certificate (Figure C-9).

Figure C-9 Viewing the CSM auto-generated secure certificate

4. In the Certificate window, open the Details tab and click Copy to File (Figure C-10).

Figure C-10 Details of CSM auto-generated secure certificate


5. The Certificate Export wizard is started. Click Next (Figure C-11).

Figure C-11 Certificate Export wizard

6. In the Export File Format window, select Base-64 encoded X.509 (.CER) and click Next (Figure C-12).

Figure C-12 Export file format


7. In the File to Export window, select the folder where to save the exported certificate and provide a name to the file where the certificate will be saved. Click Next (Figure C-13).

Figure C-13 File to export

8. The Completing the Certificate Export Wizard window shows a summary of exporting. Confirm that all information is correct and click Finish (Figure C-14).

Figure C-14 Summary of the certificate export wizard

9. You should receive confirmation that the export was successful. Click OK to conclude the process (Figure C-15).

Figure C-15 Conclusion of export process


Appendix D. LDAP structure overview

This appendix provides a brief overview of the LDAP structure. The structure of the directory used with LDAP looks like an upside down tree, with the root on the top. This is known as a directory information tree (DIT). The directory starts with a root directory and branches into 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 for 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.


� Directory tree details� Directory with DS8000 user information

D


D.1 Directory tree details

Figure D-1 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 that, branches for users, groups, or even printers.

Figure D-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 D-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 D-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’sDN of=c:\DN of=WINDOWSDN 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.

c=us

o=ibm o=xyz

ou=tucson ou=raleigh

cn=groups cn=users cn=printers

cn=admins

cn=users

cn=diskAdmin

ou=new york

deviceID=printer1 deviceID=printer37

cn=tapeAdmin

cn=superAdmin


The DN is not fixed for an object, so it 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.

D.2 Directory with DS8000 user information

Example D-2 shows an illustration from the test directory, which contains DS8000 user information that we used in preparation of this paper.

Example D-2 User attributes

dn: uid=diskAdmin,cn=users,ou=tucson,o=ibm,c=usobjectclass: inetOrgPersonobjectclass: personobjectclass: organizationalPersoncn: disksn: adminmail: [email protected]: diskAdminuserpassword: passw0rduuid: 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 the specific user attribute.

Appendix D. LDAP structure overview 101

Related publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this paper.

IBM Redbooks

The following IBM Redbooks publications provide additional information about the topic in this document. Note that some publications referenced in this list might be available in softcopy only.

� IBM DS8880 Architecture and Implementation (Release 8.3), SG24-8323

� IBM DS8880 Data-at-rest Encryption, REDP-4500

� IBM System Storage DS8000 Copy Services Scope Management and Resource Groups, REDP-4758

You can search for, view, download or order these documents and other Redbooks, Redpapers, Web Docs, draft and additional materials, at the following website:

ibm.com/redbooks

Other publications

These publications are also relevant as further information sources:

� DS8000 Command-Line Interface User’s Guide, SC27-8526-00

� DS8880 Introduction and Planning Guide, GC27-8525

Online resources

These websites are also relevant as further information sources:

� DS8000 System Storage Interoperation Center (SSIC):

https://www.ibm.com/systems/support/storage/ssic/

� IBM Support: Fix Central:

https://www.ibm.com/support/fixcentral/swg/selectFixes?product=ibm/Storage_Disk/DS8880

� DS8000 at IBM Knowledge Center:

https://www.ibm.com/support/knowledgecenter/ST5GLJ/ds8000_kcwelcome.html

� IBM Copy Services Manager:

https://www.ibm.com/support/knowledgecenter/SSESK4




https://www.ibm.com/support/fixcentral/swg/selectFixes?product=ibm/Storage_Disk/DS8880


https://www.ibm.com/systems/support/storage/ssic/




Help from IBM

IBM Support and downloads

ibm.com/support

IBM Global Services

ibm.com/services


http://www.ibm.com/support/

http://www.ibm.com/support/

http://www.ibm.com/services/

http://www.ibm.com/services/

ibm.com/redbooks

Printed in U.S.A.

Back cover

ISBN 0738456659

REDP-5460-00

®

https://www.facebook.com/IBMRedbooks

https://www.youtube.com/user/IBMRedbooks

https://twitter.com/IBMRedbooks

https://www.linkedin.com/company/2890543?goback=.fcs_GLHD_ibm+redbooks_false_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2&trk=ncsrch_hits

http://www.redbooks.ibm.com

LDAP Authentication for IBM DS8000 Systems · 1.4 Directory services and LDAP ... implementing a...

Documents

Transcript of LDAP Authentication for IBM DS8000 Systems · 1.4 Directory services and LDAP ... implementing a...