Front cover

LDAP Authentication for

IBM DS8000 Systems
Updated for DS8000 Release 9.1

Bjoern Wesselbaum
Claudio Di Celio
Bert Dufrasne
Connie Riggins
Robert Tondini
Alex Warmuth

Redpaper
IBM Redbooks

LDAP Authentication for IBM DS8000 Systems

March 2021

REDP-5460-01
 Note: Before using this information and the product it supports, read the information in “Notices” on
page vii.

Second Edition (March 2021)

This edition applies to IBM DS8900F storage systems that are available with IBM DS8000 Licensed Machine
Code (LMC) 7.9.10 (bundle version 89.10.xx.x), referred to as Release 9.1 or later.

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

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1. IBM DS8000 user authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Introduction to the DS8000 user authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Storage Authentication Service by using CSM as an LDAP proxy . . . . . . . . . . . . . . . . . 2
1.3 Remote authentication by using the native implementation . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Benefits of using remote authentication for a DS8000 system . . . . . . . . . . . . . . . . . . . . 5
1.5 Determining the remote authentication solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 2. Lightweight Directory Access Protocol for IBM DS8000 administrators . . 7

2.1 Directory services and LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Basic LDAP and directory services terms explained. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Directory entry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Nested groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 The directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Search Base of the directory tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.4 LDAP filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 LDAP binding and authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Simple bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Anonymous bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 Direct bind and authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 3. IBM DS8000 user management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 DS8000 basic user management and access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.1 Users and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Predefined default users and passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Predefined user roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Basic user management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Adding a user by using the DS GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Adding user by using the DS CLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Customized user roles and considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 Creating a customized user role by using the DS GUI . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 LDAP considerations with customized user roles . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Planning for LDAP user groups and mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 Local administrator user ID considerations with LDAP . . . . . . . . . . . . . . . . . . . . . 31
Unlocking a DS8000 admin account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.2 Security administrator mapping considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.3 Users and user groups on a remote authentication server . . . . . . . . . . . . . . . . . . 36

Chapter 4. IBM DS8000 GUI implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Configuring remote authentication by using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.1 Starting the wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

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

 4.1.2 Remote Authentication type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.3 LDAP server type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.4 LDAP Servers access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Securing the connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.5 Configuring the access mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.6 Configure Lookup Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.7 Enable Local Administrator window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.8 Authentication mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.9 Special consideration for secadmin users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.10 Administrator verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Modifying an existing configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.1 Changing the user mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.2 Changing the LDAP server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Enabling local authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 Exporting and importing the configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.1 Exporting the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.2 Importing the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 5. Implementing LDAP by using the DS Command-Line Interface . . . . . . . . 59

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 Creating a truststore for a secure LDAP connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3 Creating a remote authentication policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4 Testing and activating a remote authentication policy . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5 Managing remote authentication policies by using the DS CLI . . . . . . . . . . . . . . . . . . . 67
5.6 Special considerations for security administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.7 Special considerations for resource groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Chapter 6. Implementing LDAP with directory services . . . . . . . . . . . . . . . . . . . . . . . . 73

6.1 OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.1.1 Overlays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.1.2 Group definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2 Microsoft Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.1 Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.2 Nested group support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3 IBM Security Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.1 Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.2 Nested group support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Chapter 7. IBM Resource Access Control Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.1 Configuring secure communication between the LDAP server and a client on a DS8900F
system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.2 LDAP search base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.3 RACF user and group considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.3.1 RACF user definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.3.2 RACF group definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.4 LDAP authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.4.1 Simple binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.4.2 Direct binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.5 LDAP lookup considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.6 Authentication mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.7 RACF multi-factor authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter 8. Migrating from IBM Copy Services Manager based LDAP authentication to
native LDAP authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

iv LDAP Authentication for IBM DS8000 Systems

8.1 The migration scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8.2 Required information for the migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.2.1 Gathering the data from the DS8900F system . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Gathering the authentication policy by using the DS CLI. . . . . . . . . . . . . . . . . . . . . . 91
Gathering the authentication policy by using the DS GUI . . . . . . . . . . . . . . . . . . . . . 92
8.2.2 Gathering the CSM LDAP configuration details . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.3 Starting the migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.3.1 Changing the authentication to local authentication on the DS8900 system . . . . 95
8.3.2 Restarting the HMCs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.3.3 Configuring the native LDAP authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Chapter 9. Implementing LDAP through IBM Copy Services Manager . . . . . . . . . . . . 99

9.1 Architecture for remote authentication through CSM . . . . . . . . . . . . . . . . . . . . . . . . . 100
9.2 Differences between embedded and external CSM . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.2.1 Communication and IP ports to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.2.2 Certificates to use for building the truststore. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.3 Creating a truststore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.3.1 Obtaining the truststore files for external CSM servers. . . . . . . . . . . . . . . . . . . . 102
Synchronizing the truststore file when using two external CSM servers . . . . . . . . . 102
Exporting the truststore from the CSM server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.3.2 Creating the truststore files for an embedded CSM server . . . . . . . . . . . . . . . . . 104
Obtaining the certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Building the truststore file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.4 Configuring the CSM servers for LDAP authentication . . . . . . . . . . . . . . . . . . . . . . . . 110
9.4.1 Configuring LDAP by using the CSM GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Nested group support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.4.2 Configuring LDAP by using the CSM command line. . . . . . . . . . . . . . . . . . . . . . 113
9.5 Configuring the DS8000 system for LDAP authentication . . . . . . . . . . . . . . . . . . . . . 114
9.5.1 Using the DS Storage Manager GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Using the GUI to disable remote authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
9.5.2 Configuring DS8000 LDAP authentication by using the DS CLI . . . . . . . . . . . . . 124
Disabling the remote authentication policy by using the DS CLI . . . . . . . . . . . . . . . 128
9.6 Mapping LDAP users and groups to the DS8000 Security Administrator role . . . . . . 129

Appendix A. LDAP planning worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Choosing an LDAP implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Native LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Server details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Configuring LDAP servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Configuring LDAP by using CSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Enabling a local administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Configuring authentication mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Appendix B. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Troubleshooting by using ldapsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Troubleshooting by using dsquery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Appendix C. Exporting secure certificates by using the Google Chrome and Microsoft
Edge web browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Exporting a certificate on Microsoft Edge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Exporting a certificate on Google Chrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Contents v
 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

vi 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, 2021. vii

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.
DS8000® IBM Z® Tivoli®
FlashCopy® Insight® WebSphere®
IBM® RACF® z/OS®
IBM Security™ Redbooks®
IBM Spectrum® Redbooks (logo) ®

The following terms are trademarks of other companies:

The registered trademark Linux® is used pursuant to a sublicense from the Linux Foundation, the exclusive
licensee of Linus Torvalds, owner of the mark on a worldwide basis.

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.

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

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

viii LDAP Authentication for IBM DS8000 Systems

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 the DS8000 Release 9.1 code, a simpler, native LDAP authentication method is
supported along with the former implementation that relies on IBM Copy Services Manager
(CSM) acting as a proxy between the DS8000 and external LDAP servers.

The examples and operations that are shown in this paper refer to the DS8000 R9.1 SP1
code release bundle 89.11.33.0.

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

Bjoern Wesselbaum is a certified IT Specialist in Germany who joined the IBM Storage
Division in 1998. He has worked in different positions for IBM Storage Systems within EMEA
Advanced Technical Support, Remote Technical Support, and DS8000 Development at the
EMEA Storage Competence Center in Kelsterbach, Germany. With his DS8000 and IT
expertise, he supports clients in various pre- and post-sale projects, and teaches
client-tailored workshops about the DS8000 system. Bjoern holds a degree in information
technology / electrical engineering from the Technical University of Luebeck, Germany.

Claudio Di Celio has been with IBM Brazil in Rio de Janeiro since May 2003 working in the
Mainframe area as an L1 certified IT specialist. His focus is on DS8000, IBM TS7700, and
SAN systems for designing replication solutions for high availability (HA) at local and remote
distances. Before joining IBM, Claudio worked for 22 years in IT for a telecommunications
company. He holds degrees in computer science from FIAA University in Brazil, and has more
than 40 years if experience in the IT area.

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.

Connie Riggins is a DS8000 Copy Services and CSM subject matter expert (SME) with the
DS8000 Product Engineering group. She started working at IBM in 2015. Before joining IBM,
starting in 1991, Connie worked at Amdahl Corp. as a systems engineer and later at Softek
Storage Solutions as Product Manager of IBM Transparent Data Migration Facility for
IBM z/OS®.

© Copyright IBM Corp. 2018, 2021. All rights reserved. ix

 Robert Tondini is an IBM Consulting IT Specialist in IBM Australia and New Zealand. He has
25 years experience in IBM enterprise storage for mainframe and open systems. He joined
IBM in 2000, and since then he has been providing presales and implementation support for
high-end disk, tape, and SAN fabric systems with HA and disaster recovery (DR) solutions.
He has co-authored several IBM Redbooks publications and workshops for IBM DS8000
systems.

Alexander Warmuth is a Consulting IT Specialist at IBM European Storage Competence

Center. Working in technical sales support, he designs and promotes new and complex
storage solutions, drives the introduction of new products, and provides advice to customers,
IBM Business Partners, and sales. His main areas of expertise are high-end storage solutions
and business resilience for IBM Z® and Linux. He joined IBM in 1993. Alexander holds a
diploma in electrical engineering from the University of Erlangen, Germany.

Special thanks to the following people for their contributions to this project:

Dante Pichardo and Mark Hack

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 Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400

x LDAP Authentication for IBM DS8000 Systems

Stay connected to IBM Redbooks
򐂰 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

Preface xi
xii LDAP Authentication for IBM DS8000 Systems
 1

Chapter 1. IBM DS8000 user authentication

This chapter describes the authentication methods that are available for the IBM DS8000
family.

This chapter covers the following topics:

򐂰 Introduction to the DS8000 user authentication
򐂰 Storage Authentication Service by using CSM as an LDAP proxy
򐂰 Remote authentication by using the native implementation
򐂰 Benefits of using remote authentication for a DS8000 system
򐂰 Determining the remote authentication solution

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

1.1 Introduction to the DS8000 user authentication
The DS8000 system provides, by default, local basic user authentication. The user IDs, roles,
and their respective passwords are maintained locally within the DS8000 system. Each
individual DS8000 system has its own list of user IDs and passwords that must be maintained
separately.

To simplify the user ID management and comply with industry or company internal security
regulations, the DS8000 system can access a centralized directory service to perform user
authentication by using the Lightweight Directory Access Protocol (LDAP).

Starting with Licensed Machine Code (LMC) 7.9.10 (bundle version 89.10.92.0), referred to
as Release 9.1, the DS8900 system includes a native LDAP authentication function in
addition to the previous implementation by using an IBM Copy Services Manager (CSM)
LDAP proxy.

With the native LDAP implementation, you can directly configure the remote user
authentication with the DS Storage Manager GUI.

The remote authentication method that was previously supported by various models of the
DS8000 family uses Storage Authentication Service (SAS) and requires one or two CSM
instances. In this former implementation based on CSM, the DS8000 system relies on the
CSM authentication components to authenticate DS8000 users against the configured LDAP
directory server. This method is still supported, and is referred to in this paper as the LDAP
proxy.

This chapter provides an overview of the two remote authentication implementations, an

introduction to LDAP for DS8000 administrators, and planning aids for a successful
implementation of LDAP with your DS8900 system.

1.2 Storage Authentication Service by using CSM as an LDAP

proxy
This section describes the SAS solution that is based on the CSM LDAP proxy. This solution
remains the only choice for remote authentication for any DS8000 supported models that are
not running DS8000 Release 9.1 code. With the DS8900 Release 9.1 code or later, you may
stay with the CSM LDAP proxy-based solution or use the new native LDAP authentication.

The CSM LDAP proxy method requires at least one CSM instance that is running, and is
configured for LDAP authentication. For redundancy purpose, deploy two operational CSM
instances, with one instance as active and the other one as a standby CSM server.

Figure 1-1 on page 3 shows a typical remote authentication setup that uses the CSM server
that is provided with the DS8000 HMC. The embedded CSM on HMC is available starting with
the DS8000 LMC bundle 88.10.x for DS8880 and on all DS8900 systems. For redundancy, a
second CSM instance is used. This second instance can be also an embedded CSM instance
on another DS8880 or DS8900 system or a stand-alone instance. All supported DS8000
systems before the DS8880 system require CSM instances to be installed on separate
servers.

2 LDAP Authentication for IBM DS8000 Systems

Figure 1-1 Remote authentication environment by using CSM as an LDAP proxy

When using the LDAP authentication through CSM, the DS8000 user authenticates through
the DS Storage Manager GUI or DS Command-Line Interface (DS CLI). The authentication
request is sent to the Enterprise Storage Network Interface (ESSNI) server that is running on
the HMC.

To authenticate the user, the ESSNI server connects to the CSM authentication module.
Then, the CSM authentication module converts the request into LDAP and queries and
authenticates against the configured directory server.

From a high level, the configuration requires the following two actions:
򐂰 Configure the TLS secured SAS connection between the DS8000 system and the CSM
server.
Various manual steps are required to create a certificate truststore that is used to ensure
an encrypted and secured connection.
򐂰 Configure LDAP on CSM.
Various manual steps are required to ensure that the communication between the
directory server and the CSM server is secure.

For more information, see Chapter 9, “Implementing LDAP through IBM Copy Services
Manager” on page 99.

Chapter 1. IBM DS8000 user authentication 3

1.3 Remote authentication by using the native implementation
Starting with the DS8900 LMC 89.10.92.0, you can directly configure the remote LDAP
authentication from the DS GUI or DS CLI. CSM is no longer required for the communication
between the ESSNI and the directory server.

Figure 1-2 shows the authentication mechanism for the DS8900 native LDAP authentication.
The DS8900 ESSNI server on the HMC can now directly authenticate the user against the
directory server. The ESSNI Server uses either the LDAP or LDAPS (TLS secured LDAP)
protocol to communicate with the directory server.

This native implementation is simpler and preferred, when possible, over the CSM based
implementation.

Figure 1-2 DS8900 remote authentication environment that uses native LDAP authentication

When you want to set up remote authentication, follow the wizard guided setup in the DS GUI
or issue a set of DS CLI commands. The setup through the wizard does not require the
creation of a truststore file. All relevant information to set up a secure LDAP (LDAPs) to the
directory server can be specified through the wizard.

To establish a secure connection, the DS8900 system needs the public key of the directory
server to encrypt the authentication request. To prevent man-in-the-middle attacks, the
DS8900 system stores the certificate or certificate chain on both of its HMCs.

The certificates can be imported to the DS8900 system in two ways:

򐂰 The more convenient method is to retrieve certificates from the server by using the key
retrieval function of the setup wizard.
During the setup process, a TLS handshake with the directory server is initiated. During
the handshake, the server certificate is sent to the DS8900 HMC.
To ensure that the correct server certificate is retrieved, some details about the certificate
are presented to the user. The user must verify the certificate details to complete the
configuration.
򐂰 Manually create and upload a certificate keystore file.
This method must be used if you want the root certificate authority (CA) installed and it is
not provided by the LDAP server. In this case, you must also specify the supported format,
which must be Java KeyStore (JKS).

4 LDAP Authentication for IBM DS8000 Systems

1.4 Benefits of using remote authentication for a DS8000
system
Switching from local to remote authentication has the following advantages:
򐂰 Centralized user ID and password management.
Users can use their corporate login credentials to authenticate their DS8000 access.
Password rules and requirements are enforced at the corporate level. Users do not need
to log on to several DS8000 systems to frequently change their passwords.
򐂰 Centralized user management by using existing groups from the directory server.
For example, if a user joins or leaves the department, only one group in the directory
server must be updated. The update is reflected instantly when trying to access the
DS8000 system.
򐂰 Simplifies the enforcement of security requirements for passwords.
You do not need to implement new or updated password rules for each DS8000 system in
your data center or fix locked user accounts.
򐂰 Using the corporate log-in credentials can reduce the usage of shared user IDs, which
facilitates better auditing that might be required by company or industry regulations.

1.5 Determining the remote authentication solution

Every IT environment is unique, and you must decide what solutions best fit your existing
environment.

Starting with the DS8900 LMC 89.10.92.0, you can choose between direct authentication or
using CSM as a proxy.

For new installations, it is a best practice to use the native LDAP authentication described in
1.3, “Remote authentication by using the native implementation” on page 4. The setup and
cloning of the configuration to other DS8900 systems are easy. You should adjust your remote
authentication strategy for your new DS8900 systems toward native remote authentication. If
you want to migrate from the CSM based authentication to the native LDAP implementation,
see Chapter 8, “Migrating from IBM Copy Services Manager based LDAP authentication to
native LDAP authentication” on page 89.

For older DS8000 models or if your DS8900 system is not at Release 9.1, you must use
remote authentication through CSM, as described in 1.2, “Storage Authentication Service by
using CSM as an LDAP proxy” on page 2.

Chapter 1. IBM DS8000 user authentication 5

6 LDAP Authentication for IBM DS8000 Systems
 2

Chapter 2. Lightweight Directory Access

Protocol for IBM DS8000
administrators
This chapter introduces Lightweight Directory Access Protocol (LDAP) for DS8000
administrators. The chapter describes some fundamental LDAP concepts and terms to
facilitate communications between storage administrators and the directory services
administrator. This chapter is not DS8000 specific, but it focuses on those objects in an LDAP
environment that are relevant in configuring DS8000 remote authentication.

This chapter covers the following topics:

򐂰 Directory services and LDAP
򐂰 Basic LDAP and directory services terms explained
򐂰 LDAP binding and authentication

© Copyright IBM Corp. 2018, 2021. All rights reserved. 7

2.1 Directory services and LDAP
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, which are 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 that are 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, hostname, 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 evolved to meet these needs. LDAP defines a
standard method to access and update information in a directory. LDAP gained wide
acceptance as the directory access method of the internet, so it is widely used within
corporate intranets.

LDAP defines a communication protocol that 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 can be retrieved by the LDAP protocol.

All LDAP servers share many basic characteristics because they are based on the Request
for Comment (RFC) industry standard. However, because of implementation differences, they
are not all 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 at the IETF.org website.

8 LDAP Authentication for IBM DS8000 Systems

 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.

2.2 Basic LDAP and directory services terms explained

This section covers some basic LDAP terms and concepts through examples. The examples
assume an OpenLDAP server. Although other LDAP implementations or even variations in
OpenLDAP implementations can have a slightly different look, they all follow the same
scheme.

The following terms or concepts are essential:

򐂰 The structure and purpose of a directory entry, including the Distinguished Name (DN),
attributes, and groups.
򐂰 The Directory Information Tree (DIT) structure and the purpose of a search base and filter.
򐂰 The different concepts of binding to the directory.

Examples for LDAP servers implementations or products include the following ones:
򐂰 IBM Security™ Directory Server.
򐂰 Microsoft Active Directory (AD).
򐂰 OpenLDAP.
򐂰 The IBM z/OS Resource Access Control Facility (IBM RACF®) provides an LDAP
interface.

Although there are many other LDAP servers that are available, this paper mostly addresses
the ones that are in the above list.

2.2.1 Directory entry

Every directory entry for a specific user is made up of various single elements or
attribute-value pairs. Example 2-1 shows a typical user entry for John Doe in an OpenLDAP
directory server.

Example 2-1 Example of a person entry in an LDAP directory

# jdoe, People, ds8ksme.ibm.com
dn: uid=jdoe,ou=People,dc=ds8ksme,dc=ibm,dc=com
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
loginShell: /bin/false
homeDirectory: /home/jdoe
uid: jdoe
cn: John Doe
uidNumber: 5331
gidNumber: 2107
userPassword:: ----JOE’S----HASHED-----PASSWORD----
description: DS8000 Administrator
sn: Doe

Chapter 2. Lightweight Directory Access Protocol for IBM DS8000 administrators 9

 givenName: John
mail: [email protected]
employeeNumber: 994

In Example 2-1 on page 9, you can see that an LDAP entry contains many attribute-value
pairs:
򐂰 dn: The distinguished name
The DN of the directory entry. The DN is unique in the directory tree structure. The DN is
assembled by multiple Relative Distinguished Name (RDN) components. An RDN can
contain one or multiple attribute-value pairs.
The components of the DN string are defined by the setup of the directory server, and
consist of the following items:
– uid1
Represents the user ID. The uid contains the computer login names for an object.
– ou1
Represents the organizationalUnitName. An organizationalUnit is the piece of an
entry that represents a piece of an organization.
– dc1
Represents the domainComponent. It is one component of the DNS domain name.
򐂰 objectClass: A collection of one or more attributes
The collection of attributes describes one or multiple characteristics of an object. An object
class contains the required and optional attributes. Also, object classes can be inherited
by other object classes. The object classes are described in various RFCs.
– objectClass: person1
Represents a human being. It must contain the CommonName (cn) and Surname (sn),
and it might contain the userPassword.
– objectClass: organizationalPerson1
Represents the base entry that describes a person in relation to an organization.
– objectClass: inetOrgPerson2
Is inherited by the objectClass organizationalPerson and extends the class for internet
and intranet directory services requirements.
– objectClass: posixAccount3
Defines user attributes to map directory entries to UNIX systems.

2.2.2 Groups
Section 2.2.1, “Directory entry” on page 9 shows an example of a directory entry for a single
user.

Managing authentication at a user level only level is challenging. To make management less
granular, you can group users with similar roles or functions into a group.

1
https://tools.ietf.org/html/rfc4519
2
https://tools.ietf.org/html/rfc2798
3 https://tools.ietf.org/html/rfc2307

10 LDAP Authentication for IBM DS8000 Systems

An example of the DS8k_Administrator group is shown in Example 2-2, where John Doe is a
member of the group.

Example 2-2 Showing the members of an LDAP group

# DS8k_Administrator, group, ds8ksme.ibm.com
dn: cn=DS8k_Administrator,ou=group,dc=ds8ksme,dc=ibm,dc=com
cn: DS8k_Administrator
objectClass: groupOfNames
objectClass: top
member: uid=ppieters,ou=People,dc=ds8ksme,dc=ibm,dc=com
member: uid=jbloggs,ou=People,dc=ds8ksme,dc=ibm,dc=com
member: uid=emusterma,ou=People,dc=ds8ksme,dc=ibm,dc=com
member: uid=jdoe,ou=People,dc=ds8ksme,dc=ibm,dc=com

There are different object classes for groups. RFC519 specifies the object classes
groupOfName and groupOfUniqueNames. But, there are also exceptions, such as in
Microsoft AD, where the object class is group. The members of a group are represented with
the attribute member or uniqueMember.

When you run an LDAP query against the group, you can determine the members of this
group. However, when you want to find out to which group or groups a user belongs, it can
become more challenging:
򐂰 For example, Microsoft AD does provide the attribute memberOf in each user directory
entry, which indicates of which groups the user is a member.
򐂰 For OpenLDAP, you must enable an overlay that is called memberOf . The overlay queries
for that specific attribute4, but the attribute itself is not visible when you query the user
itself.

4 https://www.openldap.org/doc/admin24/overlays.html

Chapter 2. Lightweight Directory Access Protocol for IBM DS8000 administrators 11

 Nested groups
The group structure represents a flat hierarchy. To get a more granular grouping, you can
have a group as a member of another group. In Figure 2-1, you can see that the group
DS8k_Administrator has several members entries, and one of the members,
DS8k_Admin_Development_Environment, is a group. The group
DS8k_Admin_Development_Environment itself has two person entries as members.

Figure 2-1 Example of a nested group

When you query the members of the group DS8k_Administrator, the result returns the DN for
Piet Pietersen and Erika Mustermann and the DN for the group
DS8k_Admin_Development_Environment, but you do not get the DN for Jane Bloggs and
John Doe. Also, when you query the memberOf attribute from Jane Bloggs and John Doe, the
result is DS8k_Admin_Development_Environment but not DS8k_Administrator.

To overcome this challenge, you must traverse the different groups.

However, some LDAP servers provide an extension that allows the query of all members from
the group, including all nested groups. For example, the IBM Security Directory Server and
Microsoft AD provide such a server-side query.

2.2.3 The directory structure

The directory is organized in a tree structure that is called DIT. Figure 2-2 on page 13 shows
a simplified DIT with only two OUs.

In the real world, the DIT is much more complex and can contain other entities, such as PCs
and printers.

12 LDAP Authentication for IBM DS8000 Systems

Figure 2-2 Example of a simple Directory Information Tree

In our example, the root of our directory is the domainComponents (dc)

dc=ds8ksme,dc=ibm,dc=com, and there are two branch nodes of organizationalUnit (ou),
which have some leaf entries.

Consider the DN cn=John Doe,ou=People,dc=ds8ksme,dc=ibm,dc=com from Example 2-1 on

page 9. Look up the entry for this user in the DIT: Start on the right of the DN, in our case
dc=ds8ksme,dc=ibm,dc=com. Then, follow the tree to the branch ou=People. In ou=People,
you can find the entry with cn=John Doe.

Search Base of the directory tree

In large directories, a search of the complete directory starting at the root can take some time.
The search can be optimized by determining where the search of users or groups should be
within the DIT.

With the DS8000, you can specify the user and the group search base. By specifying the
search base, you limit the area that you search.

In the blue frame in Figure 2-3, you can see the result that is returned from searching the DIT
when limiting the group search base to group search base
ou=Groups,dc=ds8ksme,dc=ibm,dc=com.

Figure 2-3 Example for a group search base

Chapter 2. Lightweight Directory Access Protocol for IBM DS8000 administrators 13

 Limiting the search base improves the response time but also includes the risk that a too
restrictive search base might miss valid directory entries.

2.2.4 LDAP filter

You can filter the search results on the server side by applying a filter statement. The filter is
transferred to the server and applied during the search of the directory. The search filter
syntax is specified in RFC 45155.

Both search base and filters can be used to reduce the search scope: The search base
reduces the scope in the DIT height, and the filters reduce the width of the scope in the DIT.

You can define a filter for exact matches, substrings, greater or equal, less or equal, present,
and approximate match for any attribute in the directory entry. You also can use Boolean
operations like AND and OR.

You can also expand the filter to have multiple filters that are extended by Boolean operations.

Typically, you find the expression {0} as a placeholder in filters. When the LDAP directory is
queried, this placeholder is replaced by the user ID or LDAP group name.

Example 2-3 shows an illustration of the LDAP filter for the username in Microsoft AD. This
filter is a suggestion that is pre-filled when you configure Microsoft AD on a DS8000 system.

Example 2-3 A generic username filter for Microsoft AD

usernamefilter (&(sAMAccountName={0})(|(objectcategory=user)(objectclass=user)))

The expected result of this usernamefilter is the directory record of the user that is trying to
authenticate. The filter must be an exact match of the attribute sAMAccountName6 and the user
ID that is entered into the Storage Manager GUI or DS Command-Line Interface (DS CLI).
Also, the record must hold the attributes of the objectcategory user or objectclass user.

2.3 LDAP binding and authentication

This section describes the three bind methods that can be used when configuring the
DS8000 remote authentication:
򐂰 Simple bind
򐂰 Anonymous bind
򐂰 Direct bind and authentication

2.3.1 Simple bind

With a simple bind, you connect and authenticate with a technical user, which is known as the
bind user, at your directory server. The bind user connects to the directory server and queries
the directory for the DN of the user that is trying to authenticate. The bind user needs only the
authority to search the directory. When the password of the bind user is changed on the LDAP
server, the password also must be changed on each client that uses this user to query the
directory.

5
https://tools.ietf.org/search/rfc4515
6 sAMAccountName is the attribute that is used in Microsoft AD as the logon name.

14 LDAP Authentication for IBM DS8000 Systems

2.3.2 Anonymous bind
An anonymous bind is a simple bind with a zero length bind user DN or password. Some
LDAP directory servers allow anonymous bind. Some servers reject anonymous bind. Some
servers return a query result with less information than a query that is performed when using
a simple or direct bind.

2.3.3 Direct bind and authentication

With direct authentication, the bind operation to the LDAP server is directly performed with
the user ID and password that is entered. To accomplish this operation, the user’s DN must
be assembled from the entered user ID and a placeholder string. The assembly of the string
is required because it is not possible to determine the user DN by querying the directory
server before performing a bind operation.

Going back to the user John Doe in Example 2-1 on page 9, to allow the direct bind, you must
look at the user DN of John.

Example 2-4 John Doe’s Distinguished Name

uid=jdoe,ou=People,dc=ds8ksme,dc=ibm,dc=com

Now, you must change John Doe’s DN and replace his user ID value with the placeholder {0}
or {USERNAME} so that it can be used later for the direct bind.

Example 2-5 Example for the User DN placeholder

uid={0},ou=People,dc=ds8ksme,dc=ibm,dc=com

When you want to map LDAP groups, you must account for some additional considerations.
In this scenario, you must verify whether the authenticating user is also a member of a
specific group. This check is usually done by the application in the background. There are
different methods to accomplish this task:
򐂰 You can do a search to list the users and configured groups for validating the membership
of the user.
򐂰 You can run a compare operation to check whether a given group has a specific member.

In some LDAP environments, users might not be allowed to search the directory or even their
own group, or the response size is limited by the server. In this case, a ldapcompare operation
must be performed. Because an compare operation compares only specific values and
returns a limited reply like true or false or an error message, you must configure a DN
placeholder for the LDAP groups.

To configure the authentication for users that are members of a mapped group, you must
configure a group DN placeholder in addition to the user DN. To do so, go back to the
administrator group that is shown in Example 2-6.

Example 2-6 DN of the LDAP Group DS8k_Administrator

cn=DS8k_Administrator,ou=group,dc=ds8ksme,dc=ibm,dc=com

Chapter 2. Lightweight Directory Access Protocol for IBM DS8000 administrators 15

 Now, you must replace the group name with the placeholder {0} or {GROUPNAME}, as
shown in Example 2-7, so that it can be used for a direct bind of users that are member of a
configured LDAP group.

Example 2-7 Example of the group DN placeholder

cn={0},ou=group,dc=ds8ksme,dc=ibm,dc=com

16 LDAP Authentication for IBM DS8000 Systems

 3

Chapter 3. IBM DS8000 user management

This chapter explains DS8000 user and role management planning with local and Lightweight
Directory Access Protocol (LDAP) authentication policies.

This chapter covers the following topics:

򐂰 DS8000 basic user management and access
򐂰 Customized user roles and considerations
򐂰 Planning for LDAP user groups and mappings

© Copyright IBM Corp. 2018, 2021. All rights reserved. 17

3.1 DS8000 basic user management and access
Basic user management for the DS8000 system 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
system and cannot be shared with other DS8000 systems in the enterprise. Therefore, if the
same individuals must be users of multiple DS8000 systems within the enterprise, their user
IDs, passwords, and roles must be created separately and maintained individually for each
DS8000 system.

3.1.1 Users and roles

This section describes the following topics:
򐂰 Predefined default users and passwords
򐂰 Predefined user roles

Predefined default users and passwords

There are four predefined users in a new DS8000 system:
򐂰 A storage administrator user ID with the Administrator role and the following defaults:
User ID admin
Password admin
򐂰 A security administrator user ID with the Security administrator role and the following
defaults:
User ID secadmin
Password secadmin
򐂰 A user ID with the IBM engineering role. This user is used exclusively and only by
authorized IBM support personnel. It has the following default setting:
User ID engineering
򐂰 A user ID with the IBM service role. This user is used exclusively and only by authorized
IBM support personnel. It has the following default setting:
User ID service

The password of the admin and secadmin users must be changed on first login to make these
users operational. The DS GUI forces you to change the password when you log in for the
first time.

If you try to log in for the first time by using a DS Command-Line Interface (DS CLI) client
instead, the login with the default password is successful, but you cannot run any other
command until you change the password. To change the password, use the chuser command
that is shown in Example 3-1. This example is for the admin user ID and the new password is
passw0rd.

Example 3-1 Changing the password for the admin user ID

chuser -pw passw0rd admin

Use the same chuser command to change the default password for the secadmin user ID.

18 LDAP Authentication for IBM DS8000 Systems

Both storage and security administrators are required to configure and enable DS8000 data
at rest encryption. Users with the Administrator role have access to all storage image
resources except for the ones that are exclusively reserved for users with the Security
administrator role, such as generating or rekeying an encryption recovery key. Users with the
Security administrator role can initiate encryption recovery key actions, but these actions
must be approved by a user with the Administrator role.

Whenever a new user is added, an initial password is assigned by the storage or security
administrator.

At the first signon of any newly added user ID, the default/initial password must be changed.
The user ID is locked if an invalid password is entered multiple times, that is, if the number of
attempts is more than the limit that is 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 that is set by an administrator and no longer than
64 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 symbols !, @, #, $, %, &, *,(, and ).
򐂰 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.

Predefined user roles

With both DS8000 basic and remote authentication, users and groups are associated with
predefined or customized roles. Each user role determines a specific authorization level
regarding the DS8000 access and management.

To discover all the DS8000 predefined roles, go to the DS GUI main menu and select
Access → Roles, as shown in Figure 3-1.

Figure 3-1 DS GUI Access Roles

Chapter 3. IBM DS8000 user management 19

 The list of all predefined DS8000 user roles is displayed in Figure 3-2.

Figure 3-2 Predefined user roles

You can see for each user role how many user roles are local (basic) and remote (LDAP) user
mappings.

For more information about each user role, select a role and then click Actions. As shown in
Figure 3-3, you can modify remote mappings, check the actual permissions, or view the
overall properties of a user role.

Figure 3-3 User roles: Actions

Predefined user roles cannot be deleted, and the roles permissions cannot be modified. If you
need a user role with specific permissions (for example, a mix of two or more predefined
roles), then you can create customized user role, as described in 3.2.1, “Creating a
customized user role by using the DS GUI” on page 27.

Figure 3-4 on page 21 shows permissions for the Administrator user role. Expand each
section to get more information about the permissions.

20 LDAP Authentication for IBM DS8000 Systems

Figure 3-4 User role permissions

For a more detailed authorization level description for each associated predefined user role,
see Table 3-1.

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, and delete) to all
service functions and DS8000 resources. However, this user role cannot
initiate recovery key operations, which are used for data at rest encryption.
Users in this role may not be assigned to the Security administrator and IBM
Service roles.

Security This user role allows users to initiate recovery key operations and add other
administrator 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, and 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 complexes, storage units, storage images,
management consoles, arrays, ranks, and extent pools. The physical operator
role does not have access to security functions.

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

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

Chapter 3. IBM DS8000 user management 21

 Role Authorization level

IBM engineering This user role is typically assigned to IBM support personnel that perform all
service functions and other functions that might be needed. This role does not
have access to the logical configuration or data on the storage system.

IBM service This user role is typically assigned to IBM support personnel that service the
hardware (install or repair) and update firmware. This role does not have
access to the logical configuration or data on the storage system. Users in this
role cannot be assigned to any other role, and users in any other role cannot
be assigned to this role.

3.1.2 Basic user management

User management and related administrative tasks are performed by using either the DS GUI
(by using a browser) or the DS CLI.

Only users with the Administrator and Security administrator roles can add, remove, or modify
users. However, a user with the Administrator role can manage users in any role except users
with the Security administrator role. Therefore, only users with the Security administrator role
can manage users with the Security administrator role, and they cannot create or modify a
user in any other role.

Note: Users with the Security administrator role cannot be assigned to any other user role,
and users in any other user role cannot be assigned to the Security administrator role. This
situation is applicable to both basic or remote (LDAP) authentication policies.

Adding a user by using the DS GUI

To add a user by using the DS GUI, complete the following steps:
1. Sign on to the DS GUI by pointing your web browser to the following URL:
https://HMCIPAddress_or_HMCFQDN/DS8000
2. From the menu on the left, select the Access menu and click Users, as shown in
Figure 3-5.

Figure 3-5 Accessing the user management window by using the DS GUI

3. To create a user, in the Users window, click Add User (see Figure 3-6).

Figure 3-6 Add User wizard

22 LDAP Authentication for IBM DS8000 Systems

4. In the Add User window, enter a username and assign the required user role.
In Figure 3-7, the user with the role is about to add the user (mynewuser) and assign any
role except the Security administrator role, which cannot be mapped by a storage
administrator.

Figure 3-7 Mapping roles for a new user

After the required role is selected, provide the temporary password as based on
predefined password rules and click Add to continue (Figure 3-8).

Figure 3-8 Adding a user

Chapter 3. IBM DS8000 user management 23

 5. The task completion status is shown in Figure 3-9. Click Close to exit the Add User
wizard.

Figure 3-9 Add User: Task completed

After the user is created, you can modify it by selecting the user ID and selecting the required
option from the Actions drop-down menu. As shown in Figure 3-10 on page 25, you can do
the following actions:
򐂰 Map a new role if required (only one role at a time can be assigned when you use the DS
GUI).
򐂰 Reset the password if the user lost it or if it was compromised.
򐂰 Forcefully disconnect an already connected and active user.
򐂰 Remove a user.
򐂰 Check the user connection details, which display the application type (such as IBM Copy
Services Manager (CSM) or IBM Spectrum® Control) and the server TCP/IP address from
where the user is connected.
򐂰 View user properties.

24 LDAP Authentication for IBM DS8000 Systems

Figure 3-10 Modifying a user

Note: With the IBM service and IBM engineering roles, there is the Modify Access
Settings option, which you can use to restrict IBM support from accessing your DS8000
system through the DS GUI and DS CLI systems remotely (they would be accessible only
locally from the DS8000 HMC). Alternatively, you can allow for both local and remote DS
GUI and DS CLI access for IBM support users.

The option for the local DS GUI and DS CLI access does not impact IBM support’s ability
to access remotely the DS8000 HMC by using Assist on Site (AOS) for problem
determination and “business as usual” support activities.

Adding user by using the DS CLI

You can also use the DS CLI to perform user administration tasks. With DS CLI commands for
user management, you have more options than with the DS GUI when creating or modifying
users:
򐂰 Temporarily locking and unlocking a user.
򐂰 Assigning a scope that is mapped to a specific resource group (multi-tenant environment).
򐂰 Assigning more than one predefined role to a user (only for supported roles combinations,
such as for Logical operator, Physical operator, and Copy operator).

Note: Use DS CLI commands for user management when you need to assign a specific
user resource scope.

The user resource scope is matched to one or more resource group IDs that are assigned
to resource groups. If the resource group ID of a resource group matches the user
resource scope, the user is authorized to issue Copy Services requests to a logical
volume, LSS, or LCU that is assigned to the resource group.

Resource groups provide an enhanced security capability that supports the hosting of
multiple customers with Copy Services requirements that is equally suitable for a single
client with requirements to isolate the data of multiple operating system environments,
such as IBM Z, IBM i, and other open systems platforms.

For more information about user resource scope and groups, see DS8000 Copy Services,
SG24-8367.

Chapter 3. IBM DS8000 user management 25

 Here are a few DS CLI commands for user management:
mkuser Creates a user.
chuser Modifies an existing user.
lsuser Lists all defined users.
showuser Provides detailed user properties.

In Example 3-2, the mkuser command creates a user with the name mynewuser that is
assigned to the Physical operator, Logical operator and Copy operator user group roles.

Example 3-2 Adding a user by using the DS CLI

dscli> mkuser -pw passw0rd -group op_storage,op_volume,op_copy_services mynewuser
Date/Time: October 7, 2020 3:41:11 AM CEST IBM DSCLI Version: 7.9.10.275 DS: -
CMUC00133I mkuser: User mynewuser successfully created.

Unlike the DS GUI, where only one user role can be assigned to each new user, you can use
the DS CLI mkuser command to assign more than one role (group parameter).

Here are the available group parameters:

򐂰 admin (Administrator)
򐂰 ibm_engineering (Engineer)
򐂰 op_storage (Physical operator)
򐂰 op_volume (Logical operator)
򐂰 op_copy_services (Copy Services operator)
򐂰 secadmin (Security administrator)
򐂰 ibm_service (Service)
򐂰 monitor (Monitor)

After the user is successfully created, run the lsuser -l command, as shown in
Example 3-3. The output lists all users with the associated access authority levels.

Example 3-3 Listing all users

dscli> lsuser -l
Date/Time: October 7, 2020 4:54:28 AM CEST IBM DSCLI Version: 7.9.10.275 DS: -
Name Group State Scope
======================================================================
admin admin active *
mynewuser op_storage,op_volume,op_copy_services active PUBLIC
secadmin secadmin active *

You can get more information about each user by running the showuser command. As shown
in Example 3-4, mynewuser is the newly created user ID, and the command output provides
more information about this user, such as DaysToExpire = 9999 (it means that the password
expiration function is disabled).

Example 3-4 Showing the user properties

dscli> showuser mynewuser
Date/Time: October 7, 2020 6:41:46 AM CEST IBM DSCLI Version: 7.9.10.275 DS: -
Name mynewuser
Group op_storage,op_volume,op_copy_services
State active
FailedLogin 0
DaysToExpire 9999
Scope PUBLIC

26 LDAP Authentication for IBM DS8000 Systems

3.2 Customized user roles and considerations
There are situations when the predefined user roles are not suitable for all users accessing a
DS8000 system. For example, in a multi-tenant environment or when a DS8000 system is
connected to IBM Z (Count Key Data (CKD) volumes), IBM i, and other open systems hosts
(Fixed Block (FB) volumes), you might need to isolate a user’s access to a specific tenant or
host platform.

The DS8000 storage administrator can create custom user roles with a fully customized set of
permissions by using the DS GUI. This set of permissions helps to ensure that the
authorization level of each user on the system exactly matches their job role in the company,
making the system more robust against internal attacks or mistakes.

Note: Only users with the Administrator and Security administrator roles have the authority
to create a customized role.

The only way to create a customized user role is by using the DS GUI.

The DS CLI can only list all user roles that are defined on a DS8000 system, as shown in
Example 3-5, which shows a list of all predefined user roles.

Example 3-5 DS CLI list user roles

dscli> lsusergroup
Date/Time: October 9, 2020 7:09:46 AM CEST IBM DSCLI Version: 7.9.10.275 DS: -
Name
================
admin
ibm_engineering
ibm_service
monitor
no_access
op_copy_services
op_storage
op_volume
secadmin

3.2.1 Creating a customized user role by using the DS GUI

This section describes how to create a customized user role. This example can be applied to
customers with a DS8000 system that is shared for IBM Z (CKD volumes), IBM i, and other
open systems platform (FB volumes). Rather than using a generic Administrator role for all
storage administrators, you can create a customized user role for storage administrators with
access only to IBM Z (CKD) volumes, and restrict access to IBM i and other open systems
(FB) volumes. Furthermore, all other administrator role permissions can remain the same.

Chapter 3. IBM DS8000 user management 27

 Complete the following steps:
1. Sign on to the DS GUI by using the Administrator role user ID.
2. From the main menu, select Access → Roles option, as shown in Figure 3-11.

Figure 3-11 DS GUI Access Roles

3. In the Roles window, click Create Role, as shown in Figure 3-12.

Figure 3-12 Creating a customized role

4. Provide a meaningful name for this user role, and from the Select Role drop-down menu,
select the role that is like the new customized role that you are about to create. As shown
in our example in Figure 3-13 on page 29, we are going to create a storage administrator
role that will have permission to create and modify only IBM Z CKD volumes. Therefore,
the Administrator role is selected because most of the permissions remain the same.
Click Apply to copy all the default Administrator permissions.

28 LDAP Authentication for IBM DS8000 Systems

 Figure 3-13 Selecting a role

5. Now, you can modify the default permissions according to the new customized user role
requirements. As shown in Figure 3-14, the Open Systems Volumes and IBM i Volumes
and LSSs permissions are clear, and all other permissions remained unchanged.

Figure 3-14 Modifying the permissions according to the new customized user role requirements

Click Create to continue.

Chapter 3. IBM DS8000 user management 29

 6. The task completion summary window is displayed in Figure 3-15.

Figure 3-15 Task completion summary

The new customized role is now created and listed with the other predefined authorization
roles.

To verify all permissions for this newly created user role, select the user role, click the
Actions drop-down menu, and click Permissions (see Figure 3-16).

Figure 3-16 Verifying the permissions for the newly created user role

Furthermore, you can modify remote mappings, or delete or display user role properties.

30 LDAP Authentication for IBM DS8000 Systems

3.2.2 LDAP considerations with customized user roles
When defining a new remote authentication policy with any LDAP server, you must map users
and user groups that are defined in an LDAP server to the DS8000 predefined or customized
user roles.

In an environment with two or more DS8000 systems, when defining and activating a new
remote authentication policy on one DS8000 system (either by using Microsoft Active
Directory (AD), open LDAP, or IBM Resource Access Control Facility (RACF)), there is an
option to export a defined authentication policy and import it into the other DS8000 systems,
as described in 4.4, “Exporting and importing the configuration” on page 54.

The exported remote authentication policy is a compressed file that contains all the LDAP
definitions, including users and user groups mapping to the roles that are defined in the
DS8000 system. The predefined users roles are identical in each DS8000 system, but the
customized user roles must be manually created on each DS8000 system.

Even if you import the remote authentication policy to the target DS8000 system that does not
have customized user roles that are identical to the source DS8000 system, the import will be
successful. However, you must create an identical customized user role on the target DS8000
system and manually map it to the LDAP user group.

Therefore, a best practice is to create all customized user roles on each target DS8000
system before importing the new remote authentication policy.

However, if a custom role is not yet defined in the DS8000 system, importing the remote
policy creates a custom role with monitoring authority. If an authority different than monitoring
is required, the storage administrator must change it manually.

3.3 Planning for LDAP user groups and mappings

This chapter provides planning information for LDAP user groups and mappings:
򐂰 Local administrator user ID considerations with LDAP
򐂰 Security administrator mapping considerations
򐂰 Planning for DS8000 users and user groups that are defined on an LDAP server

The DS8000 storage administrator should plan the DS8000 user management with the LDAP
administrator.

3.3.1 Local administrator user ID considerations with LDAP

Only one DS8000 authentication policy can be active at a time: either the basic-local or the
remote authentication policy. When enabling the remote authentication policy, it is a best
practice to have one local user ID that is defined with the Administrator role, which can still
access the DS8000 system even with the remote authentication policy active. This
authentication design allows you to access the DS8000 system if the LDAP servers are not
available due to a planned or unplanned outage.

This administrator user ID is the only one that can disable remote authentication whenever
you must do so. Therefore, you must plan carefully who should be responsible for it.

Chapter 3. IBM DS8000 user management 31

 When the admin user ID is locked due to too many login attempts with a wrong password,
unlocking it by resetting its password to the default one by using the security recovery utility
tool on the DS8000 HMC (as described in “Unlocking a DS8000 admin account”)
automatically disables the remote LDAP authentication policy.

Therefore, rather than using the security recovery utility tool, use the DS CLI chuser
command with the pol parameter, as shown in Example 3-6.

If the local administrator user ID is accidentally locked, you can unlock it (reset its password)
by logging in to the DS8000 DS CLI with another LDAP user ID with the Administrator role
and running the chuser command, as shown in the Example 3-6. The pol parameter is
mandatory and should include the name of a Basic policy type. In our example, the Basic
policy is initialPolicy. You can use the lsauthpol command to list all authentication policies
that are defined in your DS8000 system.

Example 3-6 Resetting the password for the administrator user ID

dscli> chuser -pol initialPolicy -pw Test1234a localadmin
CMUC00363I chuser: The user account pwadmin with authentication policy
initialPolicy has been modified.

Unlocking a DS8000 admin account

The only way to unlock the default admin user ID is by using the security recovery utility tool
on the DS8000 HMC. The tool can be accessed from the DS8000 HMC Web User Interface
(WUI).

Important: The remote connection to the DS8000 HMC WUI is not supported for admin
password reset. You must be locally (on site) logged in to the DS8000 HMC WUI to reset
the admin password by using the security recovery utility tool.

In a situation where you cannot access the data center (due to logistics or it is
time-consuming process), you can contact IBM support and open a support ticket for
resetting the admin password. IBM support can do it remotely by using AOS or the Remote
Support Center (RSC) connection.

To reset the admin user ID password, complete the following steps:

1. From the DS8000 HMC, log in to the DS8000 HMC WUI and click Log on and launch the
Hardware Management Console web application, as shown in Figure 3-17 on page 33.

32 LDAP Authentication for IBM DS8000 Systems

 Figure 3-17 DS8000 HMC hyperlink to the WUI

2. In the DS8000 WUI login window, enter the credentials for the default user ID customer
and the initial default password cust0mer (see Figure 3-18).

Figure 3-18 DS8000 HMC WUI login window

Chapter 3. IBM DS8000 user management 33

 3. Select HMC Management, as shown in Figure 3-19.

Figure 3-19 DS8000 HMC WUI: HMC Management

4. In the Storage Server HMC Tasks section, click Start/Stop ESSNI, as shown in
Figure 3-20.

Figure 3-20 DS8000 HMC WUI: Start/Stop ESSNI

34 LDAP Authentication for IBM DS8000 Systems

 5. Under Security Recovery Options, click Reset to reset the admin password, as shown in
Figure 3-21.

Figure 3-21 Resetting the admin password

3.3.2 Security administrator mapping considerations

Data encryption is often one of the main storage security requirements whether it is done on
the application, server, SAN fabric, or storage level. The DS8000 system offers a
self-encrypting disk solution that uses Full Disk Encryption (FDE) disks and encryption keys
that are managed by external key managers.

If your DS8000 system has enabled data at rest encryption and you created a recovery key
during the initial setup, then you must use a user with the Security administrator role. This
recovery key is an emergency key that is used only if the defined encryption key servers are
temporarily or even permanently not accessible (planned or unplanned outage) during a
DS8000 power-on cycle.

To prevent one person from gaining access to the data, the handling of a recovery key
requires two people (separate roles):
򐂰 Security administrator user ID
򐂰 Storage administrator user ID

For more information about encryption on a DS8000 system, see IBM DS8000 Encryption for
data at rest, Transparent Cloud Tiering, and Endpoint Security (DS8000 Release 9.0),
REDP-4500.

The following rules apply for Security administrator users:

򐂰 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 concurrently.
򐂰 The secadmin user can create users only with the Security administrator authority.
򐂰 Unlike the Security administrator user, the Storage administrator user can create users
with all authorities except for users with the Security administrator role.
򐂰 Only a user that has Storage administrator authority can create, enable, and disable a
DS8000 remote authentication policy.
򐂰 Any user that has Security administrator authority can modify a previously created and
activated remote authentication policy. However, they can map only 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 the Administrator role.

Chapter 3. IBM DS8000 user management 35

 To create any remote authentication server/LDAP user or group mapping to the Security
administrator role in a remote authentication policy, you must meet the following
requirements:
򐂰 A remote authentication policy must exist (previously created and activated by a user with
the Administrator user role), but you must disable it before you can map LDAP users and
user groups to the Security administrator role. If the remote authentication policy is
enabled, log in by DS8000 local users (such as the pre-configured secadmin user ID) is
not allowed.
򐂰 Any user that has the Security administrator authority must use the DS CLI commands to
complete the mapping configuration.

3.3.3 Users and user groups on a remote authentication server

The DS8000 storage administrator must provide instructions to the LDAP administrator on
which users and user groups should be defined in the remote LDAP authentication server.

At a bare minimum, a storage administrator user group should be created in an LDAP server.
Alternatively, you can create as many user groups as you have defined user roles in each
DS8000 (predefined and customized user roles).

Table 3-2 includes a list of LDAP user groups that are commonly used for DS8000
authentication.

Table 3-2 LDAP groups that are used for DS8000 authentication
User/User group Comments Service or user ID

Storage administrator 򐂰 Required. User ID

򐂰 Users have access to all DS8000 storage
resources (except for initiating the recovery
key).
򐂰 Users in this group cannot be defined in the
Security administrator and IBM services user
groups.

Security administrator 򐂰 Required only if data at rest encryption is User ID

enabled with a recovery key.
򐂰 Users in this group cannot be defined in any
other group.

Copy Services 򐂰 Managing DS8000 Copy Services (that is, all 򐂰 Service ID for
disk replication topologies, IBM FlashCopy®, CSM
and Safeguarded copy). 򐂰 User ID for Copy
򐂰 CSM to connect to a DS8000 system. Services
򐂰 Users in this group cannot be defined in the operators
Security administrator and IBM Service user
groups.

Storage Resource 򐂰 IBM Spectrum Control. Service ID

Manager 򐂰 IBM Insight®.
򐂰 Both are used for collecting capacity and
performance data.
򐂰 Users in this group cannot be defined in the
Security administrator and IBM Service user
groups.

36 LDAP Authentication for IBM DS8000 Systems

User/User group Comments Service or user ID

IBM engineering 򐂰 IBM support for service functions. User ID

򐂰 Usually L2 support and above.
򐂰 Users in this group cannot be defined in the
Security administrator and IBM Service user
groups.

IBM service 򐂰 IBM support for hardware functions (hardware User ID

support and code upgraded).
򐂰 Users in this group cannot be defined in any
other user group.

Chapter 3. IBM DS8000 user management 37

38 LDAP Authentication for IBM DS8000 Systems
 4

Chapter 4. IBM DS8000 GUI implementation

This chapter describes how to configure Lightweight Directory Access Protocol (LDAP)
remote authentication through the DS GUI wizard. The configuration is for native LDAP
authentication.

To illustrate the configuration, we use Microsoft Active Directory (AD) as the directory service
in our example, but the configuration flow remains the same for other LDAP products.

This chapter covers the following topics:

򐂰 Configuring remote authentication by using the GUI
򐂰 Modifying an existing configuration
򐂰 Enabling local authentication
򐂰 Exporting and importing the configuration

© Copyright IBM Corp. 2018, 2021. All rights reserved. 39

4.1 Configuring remote authentication by using the GUI

Important: The configuration wizard works with the authentication policy GUILDAPPolicy
when listing the policies in DS Command-Line Interface (DS CLI) or it uses the active
policy if you selected to modify the active policy.

4.1.1 Starting the wizard

You can start the wizard from the main DS GUI window by selecting Access → Remote
Authentication from the side menu, as shown in Figure 4-1.

Figure 4-1 Remote Authentication menu

The Remote Authentication window opens. Start the wizard by clicking Configure Remote
authentication, as shown in Figure 4-2. The Configure Remote Authentication button
appears only when the DS8900 system is configured for the local authentication mode.

Figure 4-2 Remote Authentication window when local authentication is active

The Welcome window opens, as shown in Figure 4-3 on page 41. This window lists the
prerequisites for enabling remote authentication. Verify that you satisfy all the prerequisites,
and then click Next.

40 LDAP Authentication for IBM DS8000 Systems

 Figure 4-3 LDAP remote configuration wizard: Welcome window

4.1.2 Remote Authentication type

Figure 4-4 presents a choice between three types of Remote Authentication configurations:
Direct LDAP, IBM Copy Services Manager (CSM), and Import Configuration. The
configuration type that applies to our scenario in this chapter is the Direct LDAP option. Select
Direct LDAP, and then click Next.

Figure 4-4 LDAP remote configuration wizard: Select the configuration task

Chapter 4. IBM DS8000 GUI implementation 41

4.1.3 LDAP server type
The LDAP server type window opens. The username attribute, group name attribute,
group name filter, and username filter fields are automatically populated (for more
information, see 4.1.6, “Configure Lookup Method” on page 46). The values can be
overwritten at any time to line up with your organization’s setup.
For our example, we choose Microsoft Active Directory, as shown in Figure 4-5, and
then click Next.

Figure 4-5 LDAP remote configuration wizard: Select server type

4.1.4 LDAP Servers access

The Configure LDAP server window opens, as shown in Figure 4-6 on page 43.

42 LDAP Authentication for IBM DS8000 Systems

Figure 4-6 LDAP remote configuration wizard: Configure LDAP servers

For redundancy proposes, configure two LDAP servers. For added security, select the TLS
1.2 checkbox for encrypting LDAP traffic. If you do not select TLS 1.2, the LDAP network
traffic remains non-encrypted.

Make sure that the correct port is specified. The default port for a non-encryption connection
is 389 and 636 for an encrypted connection. In any case, check with your LDAP administrator
about which port number to use.

Securing the connection

If you selected TLS 1.2 for a secure connection, you must provide the communication
certificate. You can either retrieve the certificate from the LDAP servers through the HMC, or
you can create a truststore file on your own.

Chapter 4. IBM DS8000 GUI implementation 43

 Retrieving the certificate by using the retrieve function of the HMC
For this option, click Retrieve Certificates. The HMC performs a TLS handshake that
contains the public certificate and the certificate chain of the directory server. A dialog box
opens, as shown in Figure 4-7, which contains the certificate information to verify whether the
certificate is correct and can be trusted.

After you verified that the certificate details are okay, click Accept.

Figure 4-7 LDAP remote configuration wizard: Show the retrieved certificates

Uploading a truststore file by using the GUI

An alternative method is to upload the truststore by clicking Upload Truststore in the window
that is shown in Figure 4-6 on page 43,

The dialog that is shown in Figure 4-8 on page 45 appears. You must supply the truststore file
name and password, and then click Accept. For more information about how to create a
truststore file, see 5.2, “Creating a truststore for a secure LDAP connection” on page 60.

44 LDAP Authentication for IBM DS8000 Systems

 Figure 4-8 LDAP remote configuration wizard: Upload a truststore file

4.1.5 Configuring the access mode

After you configure the server details, you must configure a method for the DS8900 system to
authenticate on the HMC. Figure 4-9 shows that you have three options.

Figure 4-9 LDAP remote configuration wizard: LDAP Server authentication methods

򐂰 Simple authentication
With simple authentication, you must specify a functional user ID that is known as the bind
user. Usually, you do specify the user ID in the full Distinguished Name (DN). For a
Microsoft AD environment, you can specify the UPN or userPrincipalName. You also need
to provide the password for that user ID.

Chapter 4. IBM DS8000 GUI implementation 45

 򐂰 Anonymous authentication
Anonymous authentication is a bind request that uses simple authentication with a
zero-length bind DN placeholder or a zero-length password.
򐂰 Direct authentication
With direct authentication, the DS8900 system tries to directly perform a bind request with
the user ID and password combination that is entered in the DS GUI or DS CLI.
You must provide the required DN information. As you can see in Figure 4-10, we used the
strings {USERNAME} and {GROUPNAME} in our DN as placeholders for the actual user
and group names that are used during the log-in process. You also can use {0} as a
placeholder.

Figure 4-10 LDAP remote configuration wizard: Direct authentication

When selecting Direct authentication, specifying the Group DN placeholder is optional. The
Group DN placeholder is required when an LDAP user is not allowed to perform a search
operation on the directory server. By specifying the Group DN placeholder, the DS8900
performs a compare operation to validate a group membership for the authenticating user. If
no Group DN placeholder is specified, an LDAP search operation is performed.

Make your selection, and then click Next.

4.1.6 Configure Lookup Method

In Figure 4-11 on page 47, you must specify a search base to speed up and limit the search
in the Directory Information Tree (DIT). Also, you must specify the attributes that are used to
search the user or group.

The values for the Group membership attribute, the Username filter, and the Groupname filter
are populated with a preset value that fits most of the LDAP Server types that are specified in
4.1.3, “LDAP server type” on page 42. Those values can be adjusted to comply with any
specifics of your environment.

The checkbox for applying LDAP filter strings is enabled by default.

46 LDAP Authentication for IBM DS8000 Systems

Figure 4-11 LDAP remote configuration wizard: Configure Lookup Method with filter enabled

If you do not want to use filters, clear the Filters checkbox. Different entry fields, as shown in
Figure 4-12, then appear. You must provide the User name attribute and the Group name
attribute.

Figure 4-12 LDAP remote configuration wizard: Configure Lookup Method with filter disabled

Click Next to open the Enable Local Administrator window.

Chapter 4. IBM DS8000 GUI implementation 47

4.1.7 Enable Local Administrator window
In the Enable Local Administrator window, which is shown in Figure 4-13, click Enable to use
a local user ID with the Administrator role for the storage system, in addition to LDAP
authentication. If you enable the local Administrator role, then you can select one user ID with
the Administrator role from the User Name menu on your DS8000.

We strongly advise that you provide a local administrator as a fail-back solution if the LDAP
environment becomes unavailable.

Figure 4-13 LDAP remote configuration wizard: Enable Local Administrator

4.1.8 Authentication mapping

Now, you must map the groups that are defined on the LDAP server to the appropriate roles
that are defined on the DS8000 system. The DS8000 system has some standard roles, but
extra roles can be defined, which must be mapped to LDAP groups as well.

The storage administrator should work with the directory server administrator to configure or
identify the groups to be mapped. These groups might be existing or new ones.

Use the + or - icons to add or delete a mapping definition, as shown in Figure 4-14 on
page 49. Ensure that the spelling of the group or username exactly matches the definitions on
the LDAP server. The matching is case-sensitive.

48 LDAP Authentication for IBM DS8000 Systems

 Figure 4-14 LDAP remote configuration wizard: Configure Authentication Mappings

4.1.9 Special consideration for secadmin users

Special steps are required when secadmin users must authenticate through LDAP.

In the Configure Authentication Mappings window, complete the following steps:

1. Log in by using the DS CLI as a different session as a security administrator user.
2. Run the setauthpol command to map the users or groups with the secadmin role. (For
more information, see 5.3, “Creating a remote authentication policy” on page 62).

Note: The setauthpol command is not supported in the embedded DS CLI client.

setauthpol - action setmap -extuser user1,user2,... -dsgroup secadmin

GUILDLDAPPolicy
setauthpol - action setmap -extgroup grp1,grp2,... -dsgroup secadmin
GUILDLDAPPolicy
After the command completes, return to the wizard and click Next.

4.1.10 Administrator verification

In the Administrator Verification window, enter the username and password for the LDAP user
that is mapped to the Administrator role on the storage system.

With this verification, the DS8000 system ensures that a remote user is mapped to an
Administrator role and can access the DS8000 system after the remote authentication policy
is active.

Chapter 4. IBM DS8000 GUI implementation 49

 Figure 4-15 shows the Administrator Verification window.

Figure 4-15 LDAP remote configuration wizard: Administrator Verification

Clicking Next opens a summary window, which is shown in Figure 4-16. Review your choices
(you might need to scroll down to see all the configured options). If everything looks fine, click
Finish. Otherwise, click Back to correct any information.

Figure 4-16 LDAP remote configuration wizard: Configuration Summary

Now, you can click Finish because you completed all the necessary steps. If any information
is incorrect, you receive an error message.

Figure 4-17 on page 51 illustrates the error for a wrong password that is supplied for the Bind
user. You should go back and review your configuration.

50 LDAP Authentication for IBM DS8000 Systems

Figure 4-17 LDAP remote configuration wizard: Activation - Failed attempt

If all the correct values are supplied, the configuration completes successfully, and you get a
Task Completed status with a green check mark, as shown in Figure 4-18.

Figure 4-18 LDAP remote configuration wizard: Activation Successful

Chapter 4. IBM DS8000 GUI implementation 51

 Click Close, which opens the window that is shown in Figure 4-19. This window indicates that
you are being disconnected as a result of the Authentication Policy Change.

Figure 4-19 GUI Message: Disconnect due to a policy change

Now, you can log in to the DS8900 system by using the user that you defined in the LDAP
server. In our example in Figure 4-20, user jdoe logs in.

Figure 4-20 Sign-in dialog box of the DS Storage Manager GUI

4.2 Modifying an existing configuration

When remote authentication is active, the Remote Authentication window shows an overview
of the active configuration, as shown in Figure 4-21 on page 53. You can click the twistie next
to any field to see details about the individual fields.

52 LDAP Authentication for IBM DS8000 Systems

 Figure 4-21 Remote Authentication window when remote authentication is active

4.2.1 Changing the user mappings

You can change the user and group mappings at any time when remote authentication is
active. To change the user mappings, click the Mappings twistie, as shown in Figure 4-22.

Figure 4-22 Modifying the users and group mapping in an active remote authentication policy

You can click the ⊕ icon to add users or groups. To modify the role assignment or remove a
user or group, use the Actions drop-down menu.

4.2.2 Changing the LDAP server configuration

When you click Modify in the Remote Authentication window that is shown in Figure 4-21, the
LDAP configuration wizard starts. The wizard starts by showing the active configuration. You
can navigate the wizard the same way as you do for the initial configuration, which is
described in 4.1, “Configuring remote authentication by using the GUI” on page 40.

Chapter 4. IBM DS8000 GUI implementation 53

4.3 Enabling local authentication
When you disable remote authentication, the DS8000 system switches back to local
authentication.

Note: Disabling the remote authentication policy activates local authentication with the
policy name initalPolicy and all the configured user IDs.

When you click Disable in the Remote Authentication window, you are prompted to enter the
login details of a local user with the Administrator role, as shown in Figure 4-23. This
procedure ensures that you are able to log in as an administrator after local authentication is
activated.

Figure 4-23 Disabling remote authentication

4.4 Exporting and importing the configuration

To deploy the configuration to other DS8900 systems or to have a backup of the configuration
to address disaster recovery (DR), you can use the Export option that is shown in
Figure 4-23.

The configuration can be downloaded by using the GUI and stored on your local system. You
also can automate the download of the configuration by using DS CLI, as explained in 5.5,
“Managing remote authentication policies by using the DS CLI” on page 67.

4.4.1 Exporting the configuration

Clicking Export, as shown in Figure 4-23, opens the browser’s Save File dialog box. Use this
dialog box create and download a compressed file.

The compressed file contains a truststore file with the LDAP servers public certificates and a
JSON file describing the LDAP configuration.

54 LDAP Authentication for IBM DS8000 Systems

 Note: You can export only an LDAP remote authentication policy. The export does not
work for Storage Authentication Service (SAS) type policies.

4.4.2 Importing the configuration

You can import an LDAP configuration that was exported on any DS8900 system. For the
import, you need the following items:
򐂰 The exported compressed file.
򐂰 The user ID and password of a user that is mapped to the Administrator role.
򐂰 Ensure that the local administrator user exists before activating the policy. For more
information, see 3.2.2, “LDAP considerations with customized user roles” on page 31.

While starting the remote authentication configuration wizard, select Import Configuration,
as shown in Figure 4-24.

Figure 4-24 LDAP remote configuration wizard: Import Configuration

Chapter 4. IBM DS8000 GUI implementation 55

 As shown in Figure 4-25, you must specify the configuration file that was exported from
another DS8900 system and the bind password. The bind password is required only if the
policy has a bind user and password.

Figure 4-25 LDAP remote configuration wizard: Specify the config file and bind password

Click Next.

To activate the imported configuration, you must supply a user ID that is mapped to the
administrator role to ensure that you can log in as n administrator after activating this policy,
as shown in Figure 4-26.

Figure 4-26 LDAP remote configuration wizard: Verify the administrator

56 LDAP Authentication for IBM DS8000 Systems

Before activation, the wizard shows a summary window of the policy that you are about to
activate (see Figure 4-27).

Figure 4-27 LDAP remote configuration wizard: Configuration summary

When you click Finish in the Summary window of the configuration wizard, a task dialog
appears, as shown in Figure 4-28, where you can monitor the activation of the import task.
After the task is finished, the policy becomes active and you are logged out.

Figure 4-28 LDAP remote configuration wizard: Task Monitor for a policy import

Chapter 4. IBM DS8000 GUI implementation 57

58 LDAP Authentication for IBM DS8000 Systems
 5

Chapter 5. Implementing LDAP by using the

DS Command-Line Interface
This chapter explains how to set up remote Lightweight Directory Access Protocol (LDAP)
authentication by using the DS Command-Line Interface (DS CLI). It covers the configuration
that uses the DS8900F native LDAP client only. If you need information about how to set up
remote authentication that uses IBM Copy Services Manager (CSM) as LDAP proxy, see
Chapter 9, “Implementing LDAP through IBM Copy Services Manager” on page 99.

This chapter also describes where the GUI and DS CLI configuration differ from each other
and the additional methods that are provided by the DS CLI to manage more than one remote
authentication configuration.

Note: We explain how to implement and manage LDAP authentication with numerous
examples. However, it is beyond the scope of this publication to describe all available
commands and options. For more information, see the DS CLI inline help or go to at
IBM Knowledge Center.

This chapter covers the following topics:

򐂰 Overview
򐂰 Creating a truststore for a secure LDAP connection
򐂰 Creating a remote authentication policy
򐂰 Testing and activating a remote authentication policy
򐂰 Managing remote authentication policies by using the DS CLI
򐂰 Special considerations for security administrators
򐂰 Special considerations for resource groups

© Copyright IBM Corp. 2018, 2021. All rights reserved. 59

5.1 Overview
As an alternative to the GUI, you can also use the DS CLI to create and manage remote
authentication policies. By using the DS CLI, you can configure policies for both LDAP (for the
DS8900F native LDAP client) and Storage Authentication Service (SAS) to use with CSM as
a proxy.

Here are the main functional differences between the DS GUI and DS CLI:
򐂰 LDAP server certificates cannot be retrieved through the DS CLI directly. You must create
a keystore file and provide it with the definition of the LDAP server through the DS CLI.
򐂰 You can configure and manage multiple remote authentication policies (LDAP
configurations):
– You can have one active policy and multiple inactive policies.
– You can duplicate and rename LDAP policies by using the DS CLI.
– DS CLI supports importing and exporting remote authentication policies.
– You can import and export policies that you created with the DS CLI in the DS8900F
GUI and vice versa.

The following remote authentication-related DS CLI commands are available:

lsauthpol List remote authentication policies.
showauthpol Show policy details.
rmauthpol Delete policy.
cpauthpol Copy policy.
offloadauthpol Offload the active authentication policy (LDAP only).
setauthpol Change policy settings.
chauthpol Activate a policy.
mkauthpol Create or import a policy.

5.2 Creating a truststore for a secure LDAP connection

If you want to set up secure LDAP remote authentication, you must provide a keystore file for
the LDAP server definition. This keystore file must contain the certificate chain of the LDAP
server that you want to define. The keystone file must be an encrypted security file in the
binary Java KeyStore (JKS) format.

Here is an example of how to create this keystore file:

1. Use the open source tool openssl to request the certificates from the LDAP server. The
openssl command dumps all certificates from the LDAP server into a single file.
2. Extract the individual certificates by using another open source tool that is named awk.
3. Run the keytool that usually comes with any Java Runtime Environment (JRE) to
generate the JKS file.

Note: If you do not have access to the tools that are used in the example, there are other
methods to retrieve SSL certificates from a server and package them into a keystore file.
Refer to the security administrators in your organization to find a suitable method.

60 LDAP Authentication for IBM DS8000 Systems

Example 5-1 shows the openssl command that requests the complete communications
certificate information from a server. The parameters that are highlighted in bold must be
adjusted according to your environment:
-connect The hostname or IP address of your LDAP server with the IP port
definition for the secure LDAP protocol (port 636) separated by a
colon.
> output_file The name of the file in which the certificates are stored on your local
workstation.

Example 5-1 Retrieving the SSL certificates from a server

$ openssl s_client -showcerts -connect 9.155.112.113:636 < /dev/null 2>/dev/null
> > msad_server_1.txt

The resulting text file contains all the certificates from the certificate chain of the LDAP server.
Use the command that is shown in Example 5-2 to extract all the certificates from the text file
and store them in individual files that are distinguished by numbers. The parameters that are
in bold must be adapted to your configuration:
out=”cert file prefix” The stem of the file names for the resulting individual certificate
files.
< input_file The name of the text file containing the certificates, as
generated in Example 5-1.

In our example, the text file contains two certificates, as you can see in the second command
in Example 5-2, which lists the resulting certificate files.

Example 5-2 Extracting certificates from a text file

$ awk '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/{if(/-----BEGIN
> CERTIFICATE-----/){a++}; out="msad_server_1-"a".pem"; print > out}'
> < msad_server_1.txt
$ ls -l msad_server_1-?.pem
-rw-rw-r--. 1 user user 1415 16. Oct 16:20 msad_server_1-1.pem
-rw-rw-r--. 1 user user 1391 16. Oct 16:20 msad_server_1-2.pem

Example 5-3 show the keytool command that you use to create the JKS file that you use to
establish trust for your LDAP server in your remote authentication policy. Again, you must
adjust the parameters that are in bold for your configuration:
-keystore The name of the keystore file that you want to create.
-storepass A password for your new keystore file. You need this password later
whenever you want to use (list or modify) the keystore.
-alias An alias (name) for the entry you are adding to your keystore.
-file The name of the certificate file you want to add to the keystore.

Example 5-3 Creating the JKS file

$ keytool -import -trustcacerts -keystore msad_servers.jks
> -storepass xxxxxxxxx -noprompt -alias msad_server_cert_1
> -file msad_server_1-1.pem

Certificate was added to keystore

Chapter 5. Implementing LDAP by using the DS Command-Line Interface 61

 In Example 5-4, we add another certificate to the same keystore file as in Example 5-3 on
page 61. The command is similar. You specify a different alias and certificate file.

Example 5-4 Adding a certificate to the keystore file

keytool -import -trustcacerts -keystore msad_servers.jks
> -storepass xxxxxxxxx -noprompt -alias msad_server_cert_2
> -file msad_server_1-2.pem

Certificate was added to keystore

Continue until you added all the certificates for all the LDAP servers that you are planning to
add to your remote authentication policy.

5.3 Creating a remote authentication policy

This section explains how you can create and activate a remote authentication policy by using
an example. In the example, we connect a DS8900F system to a dual server Microsoft Active
Directory (AD) LDAP configuration by completing the following steps.

Note: The parameters in some of the commands are specific for a connection to AD. Other
LDAP implementations might require different parameters in the DS CLI commands.

1. Create an empty policy by running the mkauthpol DS CLI command, as shown in

Example 5-5.

Example 5-5 Creating a blank remote LDAP authentication policy

dscli> mkauthpol -type LDAP ldap_dscli_ad
CMUC00365I mkauthpol: The authentication policy ldap_dscli_ad has been created.

2. Configure the policy by running the setauthpol command. You must issue the command
multiple times until your policy definition is complete. The command can change only one
configuration setting at a time. The parameter of the -action keyword determines which
setting is being changed. Extra keywords and parameters might be required. Each
command is completed by specifying the policy name.

Note: The LDAP parameters that are used here are the ones that are offered as default
values when you create a Microsoft LDAP policy by using the DS8900F GUI. In the
same way, you can use the GUI defaults for LDAP implementations.

Example 5-6 shows the command to add the LDAP servers to the policy. We specify the
LDAP servers by using a full URL, including the protocol and port definition with the action.
In this case, we connect to the LDAP servers by using SSL. Therefore, the ldaps protocol
is specified and the port number is 636.

Example 5-6 Adding LDAP servers to a remote authentication policy

dscli> setauthpol -action setauthserver -loc
ldaps://9.155.112.113:636,ldaps://9.155.112.114:636 ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

62 LDAP Authentication for IBM DS8000 Systems

 Note: If you want to use LDAP without SSL, specify the protocol as ldap and use port
number 389.

In Example 5-7, we add the SSL keystore to the policy. We provide the name and location
of the keystore file and the password that is required to open it.

Example 5-7 Adding the SSL keystore to the remote authentication policy
dscli> setauthpol -action settruststore -loc /home/user/msad_servers.jks -pw
xxxxxxxx ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

In Example 5-8, we add th LDAP bind information to the policy. We want to use the simple
bind method, so we must provide a bind user and password. We need two commands:
One to add the user, and another one to provide the password.

Example 5-8 Adding the LDAP bind credential for simple binding
dscli> setauthpol -action setbinduser -binduser
"CN=bind,CN=Users,DC=ds8ksme,DC=local" ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

dscli> setauthpol -action setbindpass -bindpass xxxxxxxx ldap_dscli_ad

CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

Note: If you want to use direct binding, you do not have to specify a bind user and
password. Instead, you provide a bind Distinguished Name (DN) placeholder by using
the setuserbasedn action keyword. You can determine the placeholder from your User
Search Base DN. Use the same DN, but replace the username in the CN field with a
placeholder that can be either {0} or {USERNAME}. The LDAP client replaces it with the
user ID that tries to authenticate. For anonymous binding, no bind information must be
specified. For more information about LDAP binding, see 2.3, “LDAP binding and
authentication” on page 14.

3. In the next step, we add the LDAP search base definitions to our new policy. We need a
setauthpol command for both the user search base and the group search base definitions,
as shown in Example 5-9.

Example 5-9 Adding a user and group search base.

dscli> setauthpol -action setuserbasedn -userbasedn
"CN=Users,DC=ds8ksme,DC=local" ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

dscli> setauthpol -action setgroupbasedn -groupbasedn

"CN=Groups,DC=ds8ksme,DC=local" ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

Chapter 5. Implementing LDAP by using the DS Command-Line Interface 63

 Note: The group definition is not mandatory. You do not have to set it if you use only
direct user mappings,

In Example 5-10, we set the user and group name filters, and the group membership
attribute.

Example 5-10 Setting the username, group name, and group membership attributes
dscli> setauthpol -action setusernamefilter -usernamefilter
"(&(sAMAccountName={0})(|(objectcategory=user)(objectclass=user)))"
ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

dscli> setauthpol -action setgroupnamefilter -groupnamefilter

"(&(cn={0})(|(objectcategory=group)(objectclass=group)))" ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

dscli> setauthpol -action setgroupmemberattr -groupmemberattr "member,memberOf"

ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

Note: For other LDAP implementations, you might have to set the additional LDAP
attributes username attribute or group name attribute. If so, you can use the
setusernameattr and setgroupnameattr parameters of the setauthpol command.

It is a best practice to add an existing local user ID with admin access to a remote
authentication policy. This ID is not intended for every day use, but for specific situations.
For example, using this ID enables you to log on to the DS8900F system even when the
remote authentication servers are unavailable. Example 5-11 show the definition of a local
admin user ID.

Example 5-11 Defining a local admin user

dscli> setauthpol -action setlocaladmin -username local_admin -enable
ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

4. The basic definition of the remote authentication policy is complete, and we must add the
user and group mappings to the policy. In Example 5-12, we define two users and two
groups. For recommendations and best practices regarding the definition of users and
groups, see Chapter 3, “IBM DS8000 user management” on page 17.

Example 5-12 Adding user and group mappings

dscli> setauthpol -action addmap -extuser user0 -dsgroup admin ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

dscli> setauthpol -action addmap -extuser user5 -dsgroup op_copy_services

ldap_dscli_ad

64 LDAP Authentication for IBM DS8000 Systems

 CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

dscli> setauthpol -action addmap -extgroup DS8k_Administrator -dsgroup admin

ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

dscli> setauthpol -action addmap -extgroup DS8k_Physical_operator -dsgroup

op_storage ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been
modified.

The user and group IDs that you specify with the -extuser or -extgroup keywords must
exist in the LDAP directory. The DS8000 system queries the LDAP service for them when
users try to log on. You specify an access group with the -dsgroup keyword. Here you can
use either DS8000 predefined groups or customer-defined groups. The predefined groups
(or user roles) are the same ones that you can use when you define local users:
admin Administrator
op_storage Physical operator
op_volume Logical operator
op_copy_services Copy Services operator
monitor Monitor
auditor Auditor
no_access No Access
ibm_service IBM service representative
ibm_engineering IBM DS8000 product engineer
secadmin Security administrator

For more information about predefined and custom user roles, see IBM DS8900F
Architecture and Implementation Release 9.1, SG24-8456.

Note: User IDs with secadmin access require special considerations. For more
information, see 5.5, “Managing remote authentication policies by using the DS CLI” on
page 67.

You can also add more than one access group to an LDAP group or user. To do so, run a
setauthpol command for each DS8000 access group that you want to map to an external ID.
In Example 5-13, we map an external group to two DS8000 access groups.

Example 5-13 Defining external group mapping with more than one access role
dscli> setauthpol -action addmap -extgroup DS8k_Logical_and_copy_operator -dsgroup
op_volume ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been modified.

dscli> setauthpol -action addmap -extgroup DS8k_Logical_and_copy_operator -dsgroup

op_copy_services ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been modified.

Chapter 5. Implementing LDAP by using the DS Command-Line Interface 65

5.4 Testing and activating a remote authentication policy
After the definition of your remote authentication policy is complete, you can test and activate
it. The testauthpol DS CLI command, which is shown in Example 5-14, initiates a test of the
policy without activating it. When you run this command, the DS8900F system contacts the
LDAP servers by using the specified protocol (with or without SSL) and LDAP bind method.
Then, the system searches for the user that is provided with the command. The command is
successful if the LDAP search succeeded.

Example 5-14 Testing a remote authentication policy for a user

dscli> testauthpol -username user0 -pw xxxxxxxxx ldap_dscli_ad
CMUC00371I testauthpol: The authentication policy ldap_dscli_ad has been
authenticated on location ldaps://9.155.112.113:636.
CMUC00371I testauthpol: The authentication policy ldap_dscli_ad has been
authenticated on location ldaps://9.155.112.114:636.

With the testauthpol command, you can also verify whether the policy maps the specified
user to one or more DS8900F access groups. To do so, add the -group keyword together with
the respective access groups. Example 5-15 shows such a command that is issued against a
group mapped user whose LDAP group is mapped to two different DS8000 access groups
(see group mapping in Example 5-13 on page 65).

Example 5-15 Testing a remote authentication policy for access group mapping
dscli> testauthpol -username lcuser4 -pw xxxxxxxxx -group
op_copy_services,op_volume ldap_dscli_ad
CMUC00371I testauthpol: The authentication policy ldap_dscli_ad has been
authenticated on location ldaps://9.155.112.113:636.
CMUC00371I testauthpol: The authentication policy ldap_dscli_ad has been
authenticated on location ldaps://9.155.112.114:636.

If all your policy tests where successful, you can finally activate your new policy by using the
chauthpol -activate command, as shown in Example 5-16. For policy activation, you must
also provide a user ID with its password. This user must exist in the LDAP directory that must
be mapped to the DS8900F admin access group in the new remote authentication policy. The
command asks for a confirmation before activating the policy.

Example 5-16 Activating a remote authentication policy

dscli> chauthpol -activate -username user0 -pw Passwd#0 ldap_dscli_ad
CMUC00370W chauthpol: Are you sure that you want to modify the authentication
policy ldap_dscli_ad? [Y/N]:y
CMUC00369I chauthpol: The authentication policy ldap_dscli_ad has been modified.

After you activate a remote authentication policy, the DS8900F automatically logs you out
because your local user authentication became invalid. You must log on again with a user ID
that the DS8900F can authenticate against the LDAP service, as shown in Example 5-17.
After login, we run the whoami command. It confirms that we logged on by using the new
policy.

Example 5-17 Logging on again and verifying the user after activating the remote authentication policy
[user@linux ~]$ /opt/ibm/dscli/dscli -cfg
/home/user/tools/dscli/profile/lah81.profile -user admuser0 -passwd xxxxxxxx

66 LDAP Authentication for IBM DS8000 Systems

 dscli> whoami
Name Group Policy Scope
==================================
admuser0 admin ldap_dscli_ad *

5.5 Managing remote authentication policies by using the DS

CLI
Using the DS CLI, you can manage your authentication policies. There are commands to do
the following actions:
򐂰 List defined and active policies.
򐂰 Display a policy in detail.
򐂰 Change a policy.
򐂰 Export the active policy.
򐂰 Import a policy.

In the following sections, we explain some of the most useful commands and options.

With the lsauthpol command, you can request a list of all remote authentication policies that
are defined in a DS8900F system. As shown in Example 5-18, the command tells the listed
policies type, and whether they are active or inactive.

Example 5-18 Output of the lsauthpol command

dscli> lsauthpol
name type state
============================
CSM SAS inactive
GUILDAPPolicy LDAP inactive
initialPolicy Basic inactive
ldap_dscli_ad LDAP active

When you specify the -l flag with the lsautpol command, the command also shows the
hostname or IP addresses of the defined authentication servers in the list.

If you want to get more information about a policy, you can use the showauthpol command.
Without an additional flag, it lists all policy definitions except for the user and group mappings.
If you add the -map flag, the mappings are displayed, as shown in Example 5-19.

Example 5-19 Detailed information about a remote authentication policy

dscli> showauthpol -map ldap_dscli_ad
name ldap_dscli_ad
type LDAP
state inactive
location ldaps://9.155.112.113:636,ldaps://9.155.112.114:636
truststore msad_servers.jks
binduser CN=bind,CN=Users,DC=ds8ksme,DC=local
bindpass *****
userbasedn CN=Users,DC=ds8ksme,DC=local
groupbasedn CN=Groups,DC=ds8ksme,DC=local
usernameattr -
groupnameattr -

Chapter 5. Implementing LDAP by using the DS Command-Line Interface 67

 grouppmemberattr member,memberOf
usernamefilter
(&(sAMAccountName={0})(|(objectcategory=user)(objectclass=user)))
groupnamefilter (&(cn={0})(|(objectcategory=group)(objectclass=group)))
dnpattern -
localAdmin local_admin
localAdminEnabled Enabled
============Role Group Maps=============
DS_group Ext_group
===============================================
op_volume DS8k_Logical_and_copy_operator
admin DS8k_Administrator
op_copy_services DS8k_Logical_and_copy_operator
op_storage DS8k_Physical_operator
=============Role User Maps=============
DS_group Ext_user
=========================
admin user0
op_copy_services user5

With the -map flag, the command lists the mappings grouped by the DS8000 access roles. In
some cases, it can be useful to have the mappings grouped by the external (LDAP)
definitions. You can get the mappings listed in this reverse grouping by running the following
command:
showauthpol -revmap

If you want to change an existing policy, rub the setauthpol command. The command works
for both active and inactive policies. After you have a working policy, the most likely changes
you will make to it is the mapping of users and groups. In that context, the setauthpol
command provides the following actions:
addmap Create an external user or group mapping, or add another access role
to an existing user or group.
setmap Replace the mapping for an existing external user or group. Works as
addmap for non-existing user or groups.
rmmap Remove individual access roles from one or more existing external
users or groups.
rmallmap Remove all access roles from one or more existing external users or
groups.

For examples of the setauthpol command, see 5.3, “Creating a remote authentication policy”
on page 62.

Note: Be careful when changing the currently active policy. You might lock yourself out of
the storage system user interface.

68 LDAP Authentication for IBM DS8000 Systems

You can maintain more than one remote authentication policy, among which only one can be
active at a time. The DS CLI provides more commands that support the management of
several policies:
mkauthpol Create a policy or import one that was previously offloaded. You can
use the import function to import a policy that you created on another
DS8900F system. The import function is supported only for LDAP
policies.
testauthpol Test an inactive policy.
lsauthpol List the defined policies.
chauthpol Activate a policy. The activation of a new policy automatically
deactivates the currently active policy.
offloadauthpol Export the current active policy. The export command is supported
only for LDAP policies.
cpauthpol Duplicate an existing policy with a new policy name.
rmauthpol Remove an existing policy. You can remove only inactive policies. The
basic policy initialPolicy cannot be deleted.

For examples of the mkauthpol, testauthpol, lsauthpol, and chauthpol commands, see 5.3,
“Creating a remote authentication policy” on page 62 and 5.4, “Testing and activating a
remote authentication policy” on page 66.

When you want to export a remote authentication policy as a backup or to use it in another
DS8900F system, you must provide the name of an existing directory on your local
workstation (the system on which your DS CLI runs), as shown in Example 5-20.

Example 5-20 Exporting the current active LDAP policy

dscli> offloadauthpol /home/user
CMUC00212I offloadauthpol: completed successfully.

The exportauthpol command places a compressed file that is called settings.zip into the
specified directory. It contains at least two files:
򐂰 A JSON file that is named security.json that contains the definitions of the policy, except
for the passwords that were provided with the policy. This file applies to the local
administrator, bind user, and keystore passwords.
򐂰 The keystore file that you prepared and provided for the policy. There is no keystore file if
you specified your policy without SSL (LDAPS) support.

You can rename the file after exporting it to distinguish different policies.

Note: You cannot run the offloadauthpol command from the DS CLI that is embedded in
the DS8000 GUI.

To import a previously exported policy, run the mkauthpol command with the -import option.
You must provide the name and location of a compressed archive that contains the policy
definitions and optional keystore file, as shown in Example 5-21.

Example 5-21 Importing an LDAP policy

dscli> mkauthpol -type ldap -import /home/user/ldap_dscli_ad.zip ldap_ad_new
CMUC00597I mkauthpol: The authentication policy ldap_ad_new has been imported.

Chapter 5. Implementing LDAP by using the DS Command-Line Interface 69

 After importing, the policy contains all definitions except for the bind user password (if
required) that was provided when the policy was created.

Example 5-22 shows the details of an imported policy.

Example 5-22 Details of an imported policy

dscli> showauthpol ldap_ad_new
name ldap_ad_new
type LDAP
state inactive
location ldaps://9.155.112.113:636,ldaps://9.155.112.114:636
truststore msad_servers.jks
binduser CN=bind,CN=Users,DC=ds8ksme,DC=local
bindpass -
userbasedn CN=Users,DC=ds8ksme,DC=local
groupbasedn CN=Groups,DC=ds8ksme,DC=local
usernameattr -
groupnameattr -
grouppmemberattr member,memberOf
usernamefilter
(&(sAMAccountName={0})(|(objectcategory=user)(objectclass=user)))
groupnamefilter (&(cn={0})(|(objectcategory=group)(objectclass=group)))
dnpattern -
localAdmin local_admin
localAdminEnabled Enabled

Note: When you export a remote authentication policy (offload), the bind user password
that you might have specified is not included in the exported JSON file. You must provide it
again after importing the policy and before you can test and activate it.

5.6 Special considerations for security administrators

A DS8900F security administrator (secadmin) is a special user. Using security administrator
user IDs, clients can recover a DS8900F system with data at rest encryption if the external
key manager fails by using the DS8000 Emergency Recovery Key. For more information, see
IBM DS8000 Encryption for data at rest, Transparent Cloud Tiering, and Endpoint Security
(DS8000 Release 9.0), REDP-4500.

If you want to map secadmin user IDs or groups in your LDAP remote authentication policy,
you must take special considerations. A user with admin access can perform almost any
configuration and administration task on a DS8000 system. The only exception is that it
cannot manage secadmin users.

To map a secadmin user or group in your policy, an existing secadmin user must log on to the
DS8900F by using the DS CLI and create the policy mapping that is shown in Example 5-12
on page 64.

70 LDAP Authentication for IBM DS8000 Systems

5.7 Special considerations for resource groups
The DS8000 resource groups feature provides Copy Services scope management
capabilities. It is a function that enables policy-based limitations on DS8000 Copy Services
and enables the secure use of Copy Services functions by multiple users on a DS8000
system. The function is implemented through a DS8000 logical configuration object that is
called a resource group. For more information about resource groups, see DS8000 Copy
Services, SG24-8367.

When you use resource groups in your DS8000 configuration, you can limit certain users’
access to one or more resource groups by specifying a user resource scope (scope) for the
user. The scope is an attribute of a user ID. With local users, you specify the scope when you
create or change a user ID.

With remote authentication, you can specify user resource scopes in the user or group
mappings. Scopes that are defined in a remote authentication policy have the same effect as
local user scopes. The difference is that you can assign a scope to a group of users.

Example 5-23 shows two commands that set the user resource scope of an existing user and
group mapping.

Example 5-23 User and group mapping with user resource group scope definition
dscli> setauthpol -action setmap -extgroup DS8k_Logical_and_copy_operator -scope
tenantA ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been modified.

dscli> setauthpol -action setmap -extgroup DS8k_Logical_and_copy_operator -scope

tenantA ldap_dscli_ad
CMUC00366I setauthpol: The authentication policy ldap_dscli_ad has been modified.

Example 5-24 shows a showauthpol command that issued to the policy after setting the
scope. It contains new sections that list the user and group mappings that have a use
resource scope that is assigned.

Example 5-24 Showing user resource scopes in policy mapping

dscli> showauthpol -map ldap_dscli_ad
name ldap_dscli_ad
type LDAP
state active
...
============Scope Group Maps============
DS_scope Ext_group
=======================================
tenantA DS8k_Logical_and_copy_operator
...
============Scope User Maps=============
DS_scope Ext_user
=================
tenantA user5

Chapter 5. Implementing LDAP by using the DS Command-Line Interface 71

72 LDAP Authentication for IBM DS8000 Systems
 6

Chapter 6. Implementing LDAP with

directory services
This chapter describes special considerations with when implementing remote authentication
on a DS8900 system with the following directory services:
򐂰 OpenLDAP
򐂰 Microsoft Active Directory
򐂰 IBM Security Directory Server

© Copyright IBM Corp. 2018, 2021. All rights reserved. 73

6.1 OpenLDAP
When implementing remote authentication in an OpenLDAP environment, there are special
considerations for overlays and group definitions.

6.1.1 Overlays
With OpenLDAP, make sure that MemberOf overlay is installed.

The MemberOf overlay provides a reverse group membership relationship. The memberOf
attribute is an optional attribute, and it must be requested.

Example 6-1 shows the output of the memberOf query and the groups that UID jdoe is a
member of.

This overlay is required if you want to map Lightweight Directory Access Protocol (LDAP)
groups to the DS8000.

Example 6-1 Querying UID jdoe

$ ldapsearch -H "ldaps://my_open_LDAP_server:636" .... -b
"DC=ds8ksme,DC=ibm,DC=com" '(uid=jdoe)' memberOf
# extended LDIF
#
# LDAPv3
# base <DC=ds8ksme,DC=ibm,DC=com> with scope subtree
# filter: (uid=jdoe)
# requesting: memberOf
#

# jdoe, People, ds8ksme.ibm.com

dn: uid=jdoe,ou=People,dc=ds8ksme,dc=ibm,dc=com
memberOf: cn=DS8k_Administrator,ou=group,dc=ds8ksme,dc=ibm,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

6.1.2 Group definition

When using groups in OpenLDAP, ensure that you use the objectClass groupOfName or
groupOfUniqueNames because only those objectClass items provide the Distinguished
Name (DN) in the group configuration (posixGroups do not provide the DN).

74 LDAP Authentication for IBM DS8000 Systems

6.2 Microsoft Active Directory
When implementing DS8900 remote authentication in a Microsoft Active Directory (AD)
environment, there are special considerations for binding and nested groups.

6.2.1 Binding
By default, for Microsoft environments, Microsoft disabled anonymous binding since Windows
2003 and later.

With Microsoft AD, you can use direct binding with the userPrincipalName. No bind user is
required in this case.

You can also specify the bind user in the UPN or DN format if you want to work with a bind
user.

6.2.2 Nested group support

With Microsoft AD, you can use nested groups. To search users in nested groups, you must
specify the following configuration as the Group Member attribute when configuring Microsoft
AD remote authentication:
member:1.2.840.113556.1.4.1941:,memberOf:1.2.840.113556.1.4.1941:

The given member and memberOf attribute trigger the Microsoft server to return the results of
recursive searches of the group membership or member user DNs.

6.3 IBM Security Directory Server

When implementing DS8900 remote authentication with IBM Security Directory Server, there
are special considerations for binding and nested groups.

6.3.1 Binding
The IBM Security Directory Server supports anonymous binding. Therefore, you do not need
to have a bind user ID to query the Directory Information Tree (DIT).

6.3.2 Nested group support

With IBM Security Directory Server, you can use nested groups. To search users in nested
groups, you must specify the following configuration as the Group Member:
ibm-allmembers

The given attribute triggers the IBM Security Directory Server to return the results of recursive
searches of the group membership or member user DNs.

Chapter 6. Implementing LDAP with directory services 75

76 LDAP Authentication for IBM DS8000 Systems
 7

Chapter 7. IBM Resource Access Control

Facility
You can connect to your DS8000 system through a Lightweight Directory Access Protocol
(LDAP) server that is running on z/OS and uses the z/OS Security Server Resource Access
Control Facility (RACF) to authenticate users and groups. The LDAP server for z/OS is also
referred to as IBM Tivoli® Directory Server for z/OS. To use RACF as a user and group
repository, the LDAP server must be configured to use the Security DataBase Manager
(SDBM) back end, which acts as an interface to RACF.

For more information about how to set up the LDAP server with the SDBM back end, see IBM
Tivoli Directory Server for z/OS, SG24-7849, or IBM Knowledge Center.

Note: In the following sections, you learn much RACF terminology. If you are unfamiliar
with this terminology, refer to your RACF administrator for discussion and implementation.

In the following sections, we assume that you already have LDAP on z/OS running and
configured to use the SDBM back end. We provide details for creating only a DS8000 remote
authentication policy that is specific to z/OS or RACF.

For a detailed walk-through of the steps that are required to set up a DS8000 remote
authentication policy by using the GUI, see Chapter 4, “IBM DS8000 GUI implementation” on
page 39. If you plan to create your policy by using the DS CLI, see Chapter 5, “Implementing
LDAP by using the DS Command-Line Interface” on page 59.

Note: In the z/OS environment that we used to create the examples in this paper, the
LDAP configuration files are stored in the members of a partitioned data set (PDSE) with
the name GLD.CEBCPLEX.CNFOUT. We use this name throughout this chapter. The name will
be different in your environment.

© Copyright IBM Corp. 2018, 2021. All rights reserved. 77

 This chapter covers the following topics:
򐂰 Configuring secure communication between the LDAP server and a client on a DS8900F
system
򐂰 LDAP search base
򐂰 RACF user and group considerations
򐂰 LDAP authentication
򐂰 LDAP lookup considerations
򐂰 Authentication mappings
򐂰 RACF multi-factor authentication

7.1 Configuring secure communication between the LDAP

server and a client on a DS8900F system
It is a best practice to use secure communication between a DS8000 system that is used as
an LDAP client and the LDAP server. If your LDAP server is not configured for secure
communication, we provide a simple method to do so. Regulations in your organization might
require you to follow a different procedure.

Note: The steps in this section might have to be performed by the LDAP and RACF
administrators in your organization.

To configure the LDAP server for SSL / TLS client communication, complete the following
steps:
1. Change two LDAP configuration files. You must add the supported SSL and TLS versions
to the file that contains the LDAP server environment variable definitions. Use a text editor
in z/OS and open the GLD.CEBCPLEX.CNFOUT(DSENVVAR) file. Add or uncomment the
statements as shown in Example 7-1.

Example 7-1 Defining SSL and TLS support in the DSENVVAR member
GSK_PROTOCOL_SSLV3=ON
GSK_PROTOCOL_TLSV1=ON
GSK_PROTOCOL_TLSV1_1=ON
GSK_PROTOCOL_TLSV1_2=ON

2. Configure the LDAP server to listen for secure LDAP (LDAPS) requests. Add an extra
listen statement for LDAPS and the LDAPS IP port 636 to the general LDAP
GLD.CEBCPLEX.CNFOUT(DSCONFIG) configuration file, as shown in Example 7-2.

Example 7-2 Configuring LDAP to listen to LDAPS requests in the DSCONFIG member
...
listen ldap://:389
listen ldaps://:636
...

78 LDAP Authentication for IBM DS8000 Systems

 In the same file, you must also specify the following items:
sslAuth The SSL/TLS authentication method.
sslCertificate The label of the certificate that LDAP uses to establish trust
between the client and server.
sslKeyRingFile The path and file name of the SSL/TLS key database file, RACF
key ring name, or PKCS #11 token that contains the certificate. In
our example, we use a RACF key ring.
We provide samples for these settings in Example 7-3. They will be different in your
environment. Search the DSCONFIG member for the keywords, which provides more detail.

Example 7-3 Configuring authentication resources in the DSCONFIG member

...
sslAuth serverAuth
...
sslCertificate "LDAPSERVER SELFSIGNED"
...
sslKeyRingFile LDAPRING
...

3. You must make the SSL certificate and the key ring file accessible to the LDAP server. In
the example configuration, we use a simple method. With RACF, we create a self-signed
certificate for the LDAP servers and connect it to a RACF key ring, which we made
available to the LDAP server. The following steps explain this process. The terms in bold
match the ones in Example 7-3.
a. Generate the self-signed certificate that the LDAP server will use, as shown in
Example 7-4.

Example 7-4 Generating a self-signed certificate

RACDCERT ID(LDAPSRV) GENCERT SUBJECTSDN(CN('mcecebc.mainz.de.ibm.com') \
OU('DS8k ATS-SME') O('IBM') C('DE')) WITHLABEL('LDAPSERVER SELFSIGNED')
TRUST

b. Create the key ring for the LDAP server and add the new certificate to it, as shown in
Example 7-5.

Example 7-5 Creating the key ring and adding a certificate

RACDCERT ADDRING(LDAPRING) ID(LDAPSRV)
RACDCERT ID(LDAPSRV) CONNECT(LABEL('LDAPSERVER') RING(LDAPRING) DEFAULT)

c. Refresh the RACF certificate repository to make these changes to effective, as shown
in Example 7-6.

Example 7-6 Refreshing the RACF certificate repository

SETROPTS RACLIST(DIGTCERT) REFRESH

4. Restart the LDAP server address space. The LDAP server picks up the new settings.

Note: If you have redundant LDAP servers, you must provide a separate certificate for the
second server and add it to the LDAP key ring. You also must check whether both servers
use the same configuration files. If not, you must change both configurations.

Chapter 7. IBM Resource Access Control Facility 79

7.2 LDAP search base
You can view the LDAP search base as the root of the LDAP directory tree from where all
queries of the DS8900F LDAP client start (for more information, see 2.2.3, “The directory
structure” on page 12). You need the LDAP search base several times during the creation of a
DS8000 remote authentication policy. Therefore, we explain how to determine this parameter
up front.

In the SDBM section of the z/OS LDAP server configuration (the DSCONFIG member), you must
specify a suffix. This suffix acts as the LDAP search base for the remote authentication policy.
You can find the suffix in the LDAP server configuration file following the setting that enables
the use of the SDBM back end, as shown in Example 7-7.

Example 7-7 Finding the SDBM suffix in the LDAP for z/OS configuration file
# SDBM-specific CONFIGURATION SETTINGS

#----------------------------------------------------------------------
...
database SDBM GLDBSD31/GLDBSD64
...
#----------------------------------------------------------------------
# suffix <dn-suffix>
#
# Description:
# The suffix option specifies the root of a subtree in the namespace
# managed by this server within this backend.
#
# Example:
# suffix "sysplex=sysplex1"
#
# Notes:
# This option is required when using the SDBM backend.
#----------------------------------------------------------------------
suffix "sysplex=CEBCPLEX"

7.3 RACF user and group considerations

In this section, we explain what you must consider when defining the RACF users and groups
for DS8900F LDAP authentication. In the DS8900F remote authentication policy, you can
define two types of mappings:
򐂰 User mapping: You specify a user ID and its role. You can choose the roles from
predefined DS8000 roles or custom roles.
If a user tries to log on to the DS8000, the LDAP client first tries to find the user in the list
of user mappings. The LDAP client queries the LDAP server to check whether the user
exists in the directory and the password is correct. The LDAP server running on z/OS with
the SDBM back end verifies the query against RACF. If the query is successful, the user is
logged in with the role that you defined in the mapping.
򐂰 Group mapping: You specify a remote group and its role. The remote group must exist in
the LDAP server. You can choose the roles from predefined DS8000 roles or custom roles.
All users that are in the remote group can log in with the role that is defined for them.

80 LDAP Authentication for IBM DS8000 Systems

 If a user tries to log on to the DS8000 system and is not found in the list of direct user
mappings, the LDAP client query performs two operations:
– Checks whether the user exists and the password is correct.
– Finds out whether the user is a member of any of the groups that are defined in the
group mappings.
The LDAP server running on z/OS with the SDBM back end again verifies the query
against RACF. If the query is successful, the user is logged in with the role that you
defined in the group mapping.

Note: This explanation is simplified. In fact, each user login attempt results in multiple
LDAP queries.

7.3.1 RACF user definitions

A user ID that you define in a user mapping must meet a few conditions to be queried
successfully through LDAP:
򐂰 A user profile must exist in RACF.
򐂰 The user ID must not be revoked.
򐂰 It must have a password that is not expired. Therefore, the user ID cannot be restricted.

This set of minimum definitions allows a user ID be queried through LDAP, but does not
provide any kind of access to any resources that are managed by RACF, for example, to log in
to the z/OS system.

Tip: To make user management easier, it can be useful to add attributes. In our example,
we defined a group that is called DS8KUSER, which is the default group and owner of all
users that we use for DS8000 remote authentication. Then, we gave the owner of this
group the authority to change and reset the passwords of the users within the group. This
way, the group owner can manage some DS8000 remote user attributes without having to
involve the RACF administrator every time.

Example 7-8 shows the relevant parts of the RACF profile of one of our DS8000 users. The
terms that are marked in italic indicate the necessary attributes: non-revoked user ID, and a
valid, non-expired password. The terms in bold indicate our environment-specific group
assignment.

Example 7-8 RACF profile of a DS8000 remote authentication user

USER=DS8USR0 NAME=xxxxx OWNER=DS8KUSER CREATED=20.176
DEFAULT-GROUP=DS8KUSER PASSDATE=20.268 PASS-INTERVAL= 90 PHRASEDATE=N/A
ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE
LAST-ACCESS=20.338/12:21:28
CLASS AUTHORIZATIONS=NONE
....
LOGON ALLOWED (DAYS) (TIME)
---------------------------------------------
ANYDAY ANYTIME
GROUP=DS8KUSER AUTH=USE CONNECT-OWNER=DS8KUSER CONNECT-DATE=20.176
CONNECTS= 1,333 UACC=NONE LAST-CONNECT=20.338/12:21:28
CONNECT ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE

Chapter 7. IBM Resource Access Control Facility 81

 SECURITY-LEVEL=NONE SPECIFIED
CATEGORY-AUTHORIZATION
NONE SPECIFIED
SECURITY-LABEL=NONE SPECIFIED

7.3.2 RACF group definitions

RACF groups that you want to use for group mappings in the DS8000 remote authentication
policy must meet the following requirements:
򐂰 A group profile must exist in RACF.
򐂰 All users that can log in to the group:
– Must exist in RACF and meet the requirements that are listed in 7.3.1, “RACF user
definitions” on page 81.
– Must be connected to the group.

Again, this set of minimum definitions allows a user ID to be queried through LDAP for a
group membership, but it does not provide any kind of access to any resources that are
managed by RACF, for example, to log in to the z/OS system.

Tip: To make user and group management easier, it can be useful to add attributes. In our
example, we use the group that owns all DS8000 remote users (as described in 7.3.1,
“RACF user definitions” on page 81) also as superior group (SUPGROUP) and owner of all
remote authentication groups. Then, we give the owner of this group the authority to define
subgroups and change user to group mappings, all within the SUPGROUP. This way, the group
owner can manage the DS8000 remote user and group definitions without having to
involve the RACF administrator every time.

In Example 7-9, we show the relevant parts of the RACF profile of one of our remote
authentication groups. The terms that are marked in italic indicate the necessary attributes:
Non-revoked user ID, and a valid, non-expired password. The terms in bold indicate our
environment-specific group attributes.

Example 7-9 RACF profile for a DS8000 remote authentication group

INFORMATION FOR GROUP DS8KCOPY
SUPERIOR GROUP=DS8KUSER OWNER=DS8KUSER CREATED=20.175
NO INSTALLATION DATA
NO MODEL DATA SET
TERMUACC
NO SUBGROUPS
USER(S)= ACCESS= ACCESS COUNT= UNIVERSAL ACCESS=
CSUSR0 USE 000061 NONE
CONNECT ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE

Note: Nested groups are not supported by LDAP for z/OS and the SDBM back end, which
means that a user must be directly connected to a group that is mapped in the DS8000
remote authentication policy. You cannot connect a user through an intermediate group.

82 LDAP Authentication for IBM DS8000 Systems

7.4 LDAP authentication
The DS8000 native LDAP client supports three LDAP authentication (LDAP bind) methods:
򐂰 Simple binding
򐂰 Direct binding
򐂰 Anonymous binding

For more information about these methods, see 2.3, “LDAP binding and authentication” on
page 14.

With LDAP on z/OS and the SDBM back end, you cannot use anonymous binding. Even if the
LDAP server is configured to allow anonymous binding, RACF does not allow access to user
and group information without authentication.

In the following sections, we explain how to use the two supported binding methods.

7.4.1 Simple binding

For a simple bind, you need a dedicated bind user ID. When the LDAP client contacts the
server, it uses the bind user to authenticate and perform its query. With LDAP on z/OS with an
SDBM back end, the bind user must exist in RACF and have a password that is not expired. It
also must have authorization in RACF to query all users and groups that are relevant for the
DS8000 remote authentication.

In our example, the bind user DS8BIND is a member of the group DS8KUSER. This group
contains all user IDs that are used for DS8000 remote authentication, and it is the superior
group (SUPGROUP) for all DS8000 external groups that are defined in RACF. To query the
group, the bind user uses the AUDITOR attribute for it. Example 7-10 shows the relevant entries
in the RACF profile of this bind user.

Example 7-10 Group membership and attributes for the LDAP bind user
USER=DS8BIND ...
...
GROUP=DS8KUSER AUTH=USE CONNECT-OWNER=xxxxxxx CONNECT-DATE=20.176
CONNECTS= 00 UACC=READ LAST-CONNECT=UNKNOWN
CONNECT ATTRIBUTES=AUDITOR
...

There are other ways to provide the bind user with the necessary authorization, such as the
LISTUSER RACF command. For more information, see IBM Knowledge Center.

When you set up the DS8000 remote authentication policy, you need the bind user in LDAP
Distinguished Name (DN) format, as shown in Example 7-11. It contains the bind user’s
RACF user ID as racfid and the LDAP search base as determined in 7.2, “LDAP search
base” on page 80.

Example 7-11 Bind user Distinguished Name

racfid=DS8BIND,profiletype=user,sysplex=CEBCPLEX

Chapter 7. IBM Resource Access Control Facility 83

 Figure 7-1 shows an example of a simple bind configuration in the Configure Servers tab of
the remote authentication wizard in the DS8000 GUI. You provide the bind user DN and the
RACF password of the bind user.

Figure 7-1 Simple binding configuration in the DS8000 GUI

Note: If your LDAP server is not configured for secure communication between client and
server, the bind user password is transferred over the network in the clear. This is a high
security risk.

7.4.2 Direct binding

With direct binding, there is no dedicated bind user. Instead, the LDAP client uses the same
user ID that it uses to query the LDAP server for authentication. For simple binding, you must
specify a User DN placeholder and a Group DN placeholder in the remote authentication
policy.

Example 7-12 shows the placeholders that we use in our example. They look like a normal
user or group DN, but instead of a discrete user or group ID, they contain the variable
expression {0}. The DS8900F LDAP client replaces this variable with the user or group ID it is
querying for. The placeholders also contain the LDAP search base, as determined in 7.2,
“LDAP search base” on page 80.

Example 7-12 User and group DN placeholders for direct binding

racfid={0},profiletype=user,sysplex=CEBCPLEX
racfid={0},profiletype=group,sysplex=CEBCPLEX

Note: You can also use the variable terms {USERNAME} and {GROUPNAME} instead of {0}.

For an example of a direct binding configuration in the Configure Servers tab of the remote
authentication wizard in the DS8000 GUI using the placeholders, see Figure 7-2 on page 85.

84 LDAP Authentication for IBM DS8000 Systems

 Figure 7-2 Direct binding configuration in the DS8000 GUI

There was a limitation in the initial native LDAP implementation (DS8900F R9.1) that was
removed in the Release 9.1.1 code (bundle 89.11.5.0). This limitation required special
considerations for group mappings.

With a DS8900F release earlier than R 9.1.1, user to group mappings require that all DS8000
users that are defined in RACF have the authority to list the users in the RACF group that is
mapped in the policy. One way to provide this authorization is to give the user ID the AUDITOR
attribute for the mapped group, as shown in Example 7-13.

Example 7-13 User profile to allow group mappings with DS8900F before R 9.1SP1
USER=CSUSR0 ...
...
GROUP=DS8KCOPY AUTH=USE ...
...
CONNECT ATTRIBUTES=AUDITOR
...

7.5 LDAP lookup considerations

In this section, we explain how to determine the LDAP lookup settings for the DS8000 remote
authentication policy. You must specify the User search base and Group search base. With
DS8900F R 9.1SP and later, you also must specify a Group membership attribute. User and
group name filters can be specified optionally.
򐂰 User search base: Specify the profile type as user and add the LDAP search base, as
described in 7.2, “LDAP search base” on page 80 and shown in Example 7-14.

Example 7-14 User search base for LDAP with SDBM back end
profiletype=user,sysplex=CEBCPLEX

򐂰 Group search base: Specify the profile type as group and add the LDAP search base as
described in 7.2, “LDAP search base” on page 80 and shown in Example 7-15.

Example 7-15 Group search base for LDAP with SDBM back end
profiletype=group,sysplex=CEBCPLEX

򐂰 Group membership attribute: Specify as racfconnectgroupname.

Chapter 7. IBM Resource Access Control Facility 85

 Figure 7-3 shows how you enter these settings in the Configure Lookup window of the
DS8000 GUI.

Figure 7-3 Search base and group membership attribute for LDAP using the SDBM back end

Optionally, you can specify filters for user and group names. Filters might speed up the
background LDAP queries. For the recommended values in your organization, speak to your
LDAP administrator.

A possible simple filtering method for LDAP with the SDBM back end is to set both filters to
racfid{0}. This setting limits the searches to user and group names and omits other directory
entries. Figure 7-4 shows how you can enter these filters in the Configure Lookup window of
the DS8000 GUI.

Figure 7-4 User and group name filter examples for LDAP by using the SDBM back end

7.6 Authentication mappings

In the Authentication Mappings window, you map remote users and groups to DS8000 user
roles. The roles can either be default or custom. All remote (LDAP) users and groups you
map here must exist in RACF and meet the requirements that are described in 7.2, “LDAP
search base” on page 80. Be careful to enter the user and group ID correctly. You do not have
to consider case sensitivity because RACF knows only capital letters, so the LDAP server on
z/OS capitalizes all user and group names in its queries to RACF.

Figure 7-5 on page 87 shows the DS8000 Configure Authentication Mappings window with a
few example user and group mappings.

86 LDAP Authentication for IBM DS8000 Systems

 Figure 7-5 User and group mappings in the remote authentication policy

7.7 RACF multi-factor authentication

You can configure RACF to use MFA by implementing IBM Z Multi-Factor Authentication
(IBM Z MFA). With MFA, a user needs more than one authentication credential to log on. A
popular way to realize MFA is to use a password as something a user knows, in combination
with a one time token that is generated on a device that a user owns.

You can use the RACF back end together with IBM Z MFA for LDAP-based remote
authentication with a DS8900F system. We do not describe how to set up MFA with RACF in
this paper. For more information, see IBM Z Multi-Factor Authentication and IBM Knowledge
Center.

In the example that is used in this paper, we configure IBM Z MFA to provide a time-based
one-time password (TOTP) on a registered device, for example, a smartphone. RACF users
that are supposed to use MFA need some MFA-specific definitions in their RACF profile.

Example 7-16 shows a RACF command that enables MFA for an RACF user ID. The bold
parameters are (from left to right):
򐂰 The user ID to change.
򐂰 The extra authentication factor to use. In this case, it is AZFTOP1, which is a TOTP service.
򐂰 The tag REGSTATE:OPEN sets the Registration State to Open. Registration is required before
the user ID can perform TOTP MFA.

Example 7-16 Enabling MFA for a RACF user

ALTUSER DS8USR0 MFA(FACTOR(AZFTOTP1) TAGS(REGSTATE:OPEN)

Chapter 7. IBM Resource Access Control Facility 87

 After you set up MFA, you must register your device (smartphone) with the service that
provides the one-time passcodes before you can log in to the DS8900F system. To log in, you
use your device to generate the one time passcode with the TOTP service. Then, you open
the login prompt of the DS8000 GUI or DS CLI. You enter your user ID as usual. In the
password prompt, you provide both the one-time passcode and the password. In our
example, we use the format <one-time-passcode>:<RACF-password>.

The length of the passcode, the separation character, and which of the two credentials comes
first is defined in the IBM Z MFA configuration.

Note: Users that are configured for z/OS MFA cannot use the DS CLI that is embedded in
the DS8900F GUI. When you open the embedded DS CLI, it performs another
authentication with the DS8000 system, but your one-time token that confirms your second
authentication factor is not valid anymore. Using a stand-alone DS CLI client works. Here,
authentication, also with MFA, is performed once, and from then on the DS CLI uses it own
session tokens to secure the communication.

88 LDAP Authentication for IBM DS8000 Systems

 8

Chapter 8. Migrating from IBM Copy

Services Manager based LDAP
authentication to native LDAP
authentication
This chapter describes the requirements to migrate from the IBM Copy Services Manager
(CSM) proxy-based Lightweight Directory Access Protocol (LDAP) authentication to the
DS8900F native LDAP authentication, and removing CSM instances from the configuration.

Important: The migration is possible only for a DS8900F with Licensed Machine Code
(LMC) 89.10.92.0 or later.

This chapter covers the following topics:

򐂰 The migration scenario
򐂰 Required information for the migration
򐂰 Starting the migration

© Copyright IBM Corp. 2018, 2021. All rights reserved. 89

8.1 The migration scenario
Figure 8-1 shows a remote authentication environment that uses the CSM LDAP proxy. In this
example, one CSM server is the embedded HMC CSM server, and there is also a second,
external CSM server.

Figure 8-1 CSM based LDAP authentication

In this scenario, you change the configuration and use the new native LDAP authentication,
thus bypassing the CSM servers, as shown in Figure 8-2.

Figure 8-2 Native LDAP authentication

To switch to the native LDAP for the DS8000, changes are made only on the DS8000 system.

If the CSM servers are also used for Copy Services management and you still must log in to
CSM by using LDAP authentication, keep the LDAP configuration on the CSM servers intact.

90 LDAP Authentication for IBM DS8000 Systems

8.2 Required information for the migration
Because you are setting up a new policy, you must gather some configuration data before the
migration.

The data that is required is documented in Appendix A, “LDAP planning worksheet” on

page 131. The worksheet data can be obtained from the DS Command-Line Interface (DS
CLI), the DS Storage Manager GUI, or the CSM Server Administration window.

8.2.1 Gathering the data from the DS8900F system

You must gather all remote mapping information from the DS8900F system. You can use
either the DS CLI or GUI.

Gathering the authentication policy by using the DS CLI

To do this task, complete the following steps:
1. Determine the name of the active Storage Authentication Service (SAS) policy that you
want to migrate by running the DS CLI lsauthpol -type sas command, as shown in
Example 8-1.

Example 8-1 Listing the authentication policies of the SAS type

dscli> lsauthpol -type sas
name type state
================
CSM SAS active

2. After you obtain the name of your active SAS authentication policy, run the DS CLI
showauthpol -map command to get the mapping between the DS8900F user roles and
LDAP groups, as shown in Example 8-2.

Example 8-2 DS CLI showauthpol output showing the authentication mapping

dscli> showauthpol -map CSM
name CSM
type SAS
state active
location
https://my_CSM_1/CSMAuth/TokenService,https://my_CSM_2:9562/CSMAuth/TokenService
truststore CSM_trustStore.jks
sasuser nauser0
localAdmin admin
localAdminEnabled Enabled
============Role Group Maps=============
DS_group Ext_group
======================================
admin DS8k_Administrator
op_volume DS8k_Logical_Operator
op_storage DS8k_Physical_operator
ibm_engineering DS8k_IBM_Engineering
ibm_service DS8k_IBM_Service
=============Role User Maps=============
DS_group Ext_user
=================
secadmin user9

Chapter 8. Migrating from IBM Copy Services Manager based LDAP authentication to native LDAP authentication 91
 You need the Role Group Maps and the Role User Maps to re-creating the mapping later.

Gathering the authentication policy by using the DS GUI

To do this task, complete the following steps:
1. From the main DS GUI window, display the current remote authentication information by
selecting Access → Remote Authentication, as shown in Figure 8-3.

Figure 8-3 DS GUI selection for Remote Authentication

2. Write down all the mappings that you can see in the Remote Authentication Mappings
section. You might need to scroll down within that section. In the section header of
Figure 8-4, you can see the number of configured mappings.

Figure 8-4 DS Storage Manager showing the Remote Mappings

Now, you have the mapping of the LDAP groups and users to the DS8900F roles.

8.2.2 Gathering the CSM LDAP configuration details

You can now gather the connection details for the LDAP servers by completing the following
steps:
1. Log in to CSM as an administrator and select Settings → Administration, as shown in
Figure 8-5 on page 93.

92 LDAP Authentication for IBM DS8000 Systems

 Figure 8-5 CSM Settings menu

2. In the Administration window, click Modify, as shown in Figure 8-6.

Figure 8-6 CSM User Administration window

Chapter 8. Migrating from IBM Copy Services Manager based LDAP authentication to native LDAP authentication 93
 The LDAP Configuration window opens, as shown in Figure 8-7. From this window, you
can obtain the authentication server IP address or hostname, and the port in use for the
authentication service.

Figure 8-7 CSM LDAP configuration window

In addition, the window shows the bind user Distinguished Name (DN) or the User
Principle Name for ID that is used for the bind user.

Note: CSM uses anonymous or simple binding.

If you are in a Microsoft Active Directory (AD) environment, you might not need the bind user
if you configure the DS8900F system with direct bind. (for more information, see 4.1.5,
“Configuring the access mode” on page 45).

Write down the searchbase. Even if there is only one searchbase in CSM for users and
groups, you might want to specify a more granular searchbase when configuring the native
LDAP authentication. For more information, speak to your LDAP administrator.

8.3 Starting the migration

At this stage, you collected the configuration details that you need to migrate to the native
LDAP implementation. This migration is a disruptive action, and you must schedule a change
window for when to perform it.

Important: During the migration, remote users cannot log in. This situation impacts the
automation and monitoring procedures that might be used by CSM, IBM Spectrum Control,
or other monitoring and management software.

94 LDAP Authentication for IBM DS8000 Systems

 The migration consists of three main steps:
1. Changing the authentication to local authentication on the DS8900 system.
2. Restarting the HMCs.
3. Configuring the native LDAP authentication.

8.3.1 Changing the authentication to local authentication on the DS8900

system
Use the DS GUI or DS CLI to disable remote authentication, as described in 4.3, “Enabling
local authentication” on page 54.

8.3.2 Restarting the HMCs

To continue, you must restart both HMCs separately by using the DS GUI. Complete the
following steps:
1. From the main DS GUI window, select Settings → Support, as shown in Figure 8-8.

Figure 8-8 The Support menu

2. In the Support menu, select the Troubleshooting tab, as shown in Figure 8-9. Click
Restart Remote HMC.

Figure 8-9 Troubleshooting tab with the Restart HMC menu

Chapter 8. Migrating from IBM Copy Services Manager based LDAP authentication to native LDAP authentication 95
 3. After you click Restart Remote HMC, a dialog box opens and prompts you to confirm that
you want to restart the remote HMC, as shown in Figure 8-10. Click Yes.

Figure 8-10 Dialog box for the Restart Remote HMC action

The remote HMC restarts. Figure 8-11 shows that the state of the Remote HMC is “Offline
with redundancy”.

Figure 8-11 HMC restarting

Wait until the status changes from “Offline with redundancy” back to “Online”.
4. When the state is “Online” again, click Restart local HMC. When restarting the local
HMC, you must wait approximately 5 minutes before you can access the system again.
Then, you can refresh your browser to point to the HMC login page and log in again.
The dialog box that is shown in Figure 8-12 opens after you click Restart local HMC.

Figure 8-12 Dialog box to restart the local HMC

After both HMCs restart, you can configure the native LDAP authentication.

96 LDAP Authentication for IBM DS8000 Systems

8.3.3 Configuring the native LDAP authentication
To configure the native LDAP authentication, you can use either of the following procedures:
1. Create a configuration by using either of the following approaches:
– Use the GUI, as described in 4.1, “Configuring remote authentication by using the GUI”
on page 40.
– Use the DS CLI, as described in 5.3, “Creating a remote authentication policy” on
page 62.
2. Import an LDAP policy by using either of the following approaches:
– Use the GUI, as described in 4.4, “Exporting and importing the configuration” on
page 54.
– Use the DS CLI, as described in 5.5, “Managing remote authentication policies by
using the DS CLI” on page 67.

Chapter 8. Migrating from IBM Copy Services Manager based LDAP authentication to native LDAP authentication 97
98 LDAP Authentication for IBM DS8000 Systems
 9

Chapter 9. Implementing LDAP through IBM

Copy Services Manager
This chapter explains how to implement Lightweight Directory Access Protocol (LDAP)
remote authentication for the IBM DS8880 system through IBM Copy Services Manager
(CSM). It starts with a review of the architecture and highlights the differences with the new,
native LDAP implementation.

Because the CSM-based method is not the preferred authentication method for the DS8900F
system, we show the configuration that is based on the DS8880 GUI, but this configuration
also applies to the DS8900F system.

This chapter covers the following topics:

򐂰 Architecture for remote authentication through CSM
򐂰 Differences between embedded and external CSM
򐂰 Creating a truststore
򐂰 Configuring the CSM servers for LDAP authentication
򐂰 Configuring the DS8000 system for LDAP authentication
򐂰 Mapping LDAP users and groups to the DS8000 Security Administrator role

© Copyright IBM Corp. 2018, 2021. All rights reserved. 99

9.1 Architecture for remote authentication through CSM
As described in 1.2, “Storage Authentication Service by using CSM as an LDAP proxy” on
page 2, you need at least one CSM instance to enable remote authentication for the
DS8900F system with a code bundle earlier than 89.10.92.0, or for any DS8880 or DS8870
systems. For redundancy, deploy two CSM instances.

Tip: There is no restriction on the number of DS8000 systems that may connect to a CSM
instance for remote authentication.

For remote authentication, you can use the HMC embedded CSM instance, which is available
with any DS8900 or DS8880 system, and a CSM instance that is installed on an independent
distributed server (also referred to as external CSM). You can mix the embedded and external
CSM servers in your configuration.

Figure 9-1 shows an example of a remote authentication implementation that is using two
CSM instances for the remote authentication when the login is done through the Storage
Manager GUI or DS Command-Line Interface (DS CLI). Only the two CSM servers are
connecting through the LDAP protocol to the directory server. All DS8000 HMCs
communicate with the CSM instance to authenticate the users.

Figure 9-1 Overview of a remote authentication implementation with CSM

For this implementation, you must set up LDAP in CSM and create a single version of the
keystores, which then can be deployed to all DS8000 systems in the environment. Using this
approach can reduce the administrative overhead to maintain several CSM servers that you
might use only for remote authentication.

100 LDAP Authentication for IBM DS8000 Systems

9.2 Differences between embedded and external CSM
There are some important differences between embedded and external CSM instances to
which you must pay close attention for a successful implementation.

9.2.1 Communication and IP ports to use

Important: Make sure that you review the ports in use in accordance with your
configuration.

Table 9-1 shows the CSM IP ports that are required for configuring authentication.

Table 9-1 CSM IP ports that are required for configuring authentication
Tool Non-changeable port CSM on Default port CSM on a
the DS8900 / DS8880 HMC distributed system

CSM GUI 443 9559

CSM Authentication Service 443 9562

(CSMAuth)

CSM command-line interface 443 9560

(CLI)

Active/Standby 443 9561

The DS8900F and DS8880 security settings require that the CSM is reachable through port
443 only, as described in 9.1, “Architecture for remote authentication through CSM” on
page 100. For more information, see IBM Knowledge Center.

The port reassignment is done within the DS8000 HMC web server to serve different web
services through port 443 and provide one common TLS certificate for all available services.
You must take special care when you export the certificates for later use.

9.2.2 Certificates to use for building the truststore

When creating the truststore file that is required to use the Storage Authentication Service
(SAS) method, you must carefully consider which certificates are placed in this truststore:
򐂰 When using an external CSM instance, you can use the Export Truststore for Remote
Connection option from the CSM Settings → Advanced Tools menu.
򐂰 When using an embedded CSM instance on a DS8900F or DS8880 HMC, you must build
the truststore file on your own by using the communication certificate from the individual
HMC.
For more information about how to create the truststore, see 9.3, “Creating a truststore” on
page 102.

Chapter 9. Implementing LDAP through IBM Copy Services Manager 101

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

The truststore file contains the certificate of each CSM server that is used by the DS8000
system for the LDAP authentication. The certificates in the truststore are used to secure the
connection between the DS8000 HMC and the CSM server.

The truststore file is a Java KeyStore (JKS) file that is maintained by using the keytool
command, or iKeyman, which is available in the IBM Java distribution only. In the keystore file,
you store the certificates of the CSM servers that are used for remote authentication.

Important: If you reinstall the CSM server without a backup or if the HMC is rebuilt by
IBM Service personnel, new certificates might be created. In this case, you must create a
truststore file and import those certificates by using the DS GUI or DS CLI.

If you are using an external CSM server, complete the instructions in 9.3.1, “Obtaining the
truststore files for external CSM servers” on page 102. If you are using the HMC embedded
CSM server, go to 9.3.2, “Creating the truststore files for an embedded CSM server” on
page 104.

9.3.1 Obtaining the truststore files for external CSM servers

When creating the truststore, you must differentiate among several scenarios:
򐂰 Obtaining the truststore for two external CSM servers.
򐂰 Using one external CSM server.
򐂰 Using one or two embedded CSM servers on a DS8900 or DS8800 HMC or one
embedded and one external CSM server.

Synchronizing the truststore file when using two external CSM servers

Note: This step is required only if you have two external CSM servers. Otherwise, go to
9.3.2, “Creating the truststore files for an embedded CSM server” on page 104.

When you have two external CSM servers, you can use the CSM GUI or csmcli to copy the
certificate that is used for the authentication service from one CSM server to the other CSM
server.

Complete the following steps:

1. Log in to CSM and go to Settings → Advanced Tools, and then click Synchronize, as
shown in Figure 9-2 on page 103.

102 LDAP Authentication for IBM DS8000 Systems

 Figure 9-2 CSM GUI: Settings - Advanced Tools section to synchronize the truststore file

2. In the Synchronize Server dialog box that is shown in Figure 9-3, enter the details of the
second CSM server. After you click Synchronize, the truststore for the remote
authentication is overwritten on the CSM server that is specified.

Figure 9-3 CSM GUI: Synchronize Server to specify the access information to your other CSM
server

3. To ensure that the synchronization of the truststore was successful, check the CSM
console log for an IWNR4980 message.

Figure 9-4 CSM GUI: Console showing a successful synchronization

Chapter 9. Implementing LDAP through IBM Copy Services Manager 103

 4. After you confirm that the synchronization is complete, restart the csmAuth component of
the other CSM server. (You must stop and start the CSM authentication server.) To
complete this task, see the following resources:
– Stopping the Copy Services Manager authentication server
– Starting the Copy Services Manager authentication server
5. You successfully completed the synchronization of the certificate that is required for the
remote authentication. Because both CSM servers now have the same certificate, you can
continue the setup.

The synchronization of the truststore can also be performed running the CSMcli
syncauthservice command.

Exporting the truststore from the CSM server

Attention: This step is required only if you work with one or two external CSM servers. Do
not perform those actions if you are using CSM on a DS8880/DS8900 HMC.

After you synchronize the truststore as described in “Synchronizing the truststore file when
using two external CSM servers” on page 102, you must perform the following steps on only
one CSM server, as though you were dealing with only one external CSM server.

You must export the truststore from your CSM server through the CSM GUI. The export
function is under the Settings → Advanced Tools menu. Figure 9-5 shows the Export
Truststore for Remote Connections section in the Advanced Tools window.

Figure 9-5 CSM GUI: Settings - Advanced Tools section to export the truststore file

After you click Export, the file dialog of your browser opens, and you can download the
truststore file to the system running the browser.

Use the truststore file that you downloaded as the truststore file to configure SAS-type remote
authentication on your DS8000. The password for the truststore file is passw0rd.

9.3.2 Creating the truststore files for an embedded CSM server

Attention: This section applies when you are using an embedded CSM server on the
DS8880 or DS8900 HMCs or you are working in a mixed setup of embedded and external
CSM servers.

104 LDAP Authentication for IBM DS8000 Systems

When working with a DS8000 HMC embedded CSM, the certificates that are used by CSM
are replaced by the HMC certificate. Therefore, the CSM on-board methods for synchronizing
and exporting the truststore do not apply. In the following sections, we explain how to obtain
the DS8000 certificates and how to create the truststore files. To create the truststore, you
need the DS8000 certificates in Privacy Enhanced Mail (PEM) format. The PEM certificate
file is Base64 encoded and can be opened in a text editor.

Obtaining the certificate

You can obtain the certificate in different ways:
򐂰 Run the openssl command.
򐂰 Use a web browser.
򐂰 If a certificate authority (CA) signed certificate is installed on your HMCs, ask the person
who installed the certificates for a copy of the CA signed certificate and the certificate
chain.

The most convenient way is to use the openssl command. The openssl tool is part of the
most Linux and Unix distributions. On Windows systems, you can install an openssl port for
Microsoft Windows or use the web browser.

Obtaining the certificate with openssl

To obtain the HMC certificate and the certificates of the certificate chain, run the following
command:
openssl s_client -showcerts -connect [HMC_IP_or_FQDN]:443

Copy each certificate block into a separate file, including the lines containing BEGIN
CERTIFICATE and END CERTIFICATE. Example 9-1 shows a single certificate block.

Example 9-1 PEM format of a certificate that is obtained by running openssl

-----BEGIN CERTIFICATE-----
MIIDvzCCAqegAwIBAgICUYgwDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMx
CzAJBgNVBAgMAlRYMQwwCgYDVQQKDANJQk0xGzAZBgNVBAsMEkRTODAwMCBEZXZl
bG9wbWVudDE0MDIGA1UEAwwrRFM4MDAwIERldmVsb3BtZW50IEludGVybWVkaWF0
ZSBDZXJ0aWZpY2F0ZTAgGA8yMDIwMTAxMjAwMDAwMFoXDTIwMTAxNTE1MTgyOVow
gYkxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJBWjEPMA0GA1UEBwwGVHVjc29uMQww
CgYDVQQKDANJQk0xFTATBgNVBAsMDGRlZmF1bHRWYWx1ZTEXMBUGA1UEAwwObXlE
UzhrLmlibS5jb20xHjAcBgkqhkiG9w0BCQEWD25vcmVwbHlAaWJtLmNvbTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL89IC5KXwzKI+Xx0qRcVyP5Ef/X
JCDUf+rXEttCwFNfid930i6Pk9qmcujf0TqyaqxEFjloXT3U4C0ag0fP1JWaHbCM
tHyu4+PeL5Glyb5yXDdsmAykUlFf0Km4eZnzscZXSleJ9qJncIHR18omyflH4BVV
44O9edfxw/jGBCKdtxiY6NCiizqFRvT95JmD6STGvEnXqZ3ijuhrqRuuAbgM0p31
Zbkkd0N6J4ktgftOlVMP5Ie0Xt/kF+WNq2kCMkKMow4cQi3ETfzNmtsxiAAJcF2u
4HMq3k5AEf9ew6ek8xhEPBZOKT3YXxJ/cqdp5u6ViBQw+txcLxWGwcybIcECAwEA
AaM8MDowCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYB
BQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBCwUAA4IBAQCPUPiqdK3FbejrJllE
MJ7UA18PEuibpHuqRShpeOKuHsmx/lcqHalNYFRH2vmhwVvbNr0VVTcWH9u0TbVi
x5az7MlyadypwOF1bOvCA+UQhB0ITotwACD8Ohq8G+ij5pGt4o8B0NZyo2G/ErCI
dCfNfvXZt5b7+e2qYoVp798+SXw7blw6AMUjXKJQstNq3vINs+lJGnuUxELWCRqd
fq1Ra9DTeJdYJ3gyh5UOrTxMfhrM9bIbXERABs6WTLTXMW9Yng+EH8O2Tza2f67R
GJ295N0q2HMGCg/iO/OUhDIXsRzBcwJejJWsoGl4QrHlemw2tr+RBCF4x8atk0eZ
ujAw
-----END CERTIFICATE-----

Chapter 9. Implementing LDAP through IBM Copy Services Manager 105

 You must store all certificates in separate files because you must import the certificates one
by one into your truststore later.

If you want to obtain the certificate from the external CSM server, you must use the same
openssl command, but you specify port 9562 instead:
openssl s_client -showcerts -connect CSM_Server:9562

Obtaining the certificate by using a web browser

For our example of obtaining the certificate by using a web browser, we use Mozilla Firefox as
the browser. To use Microsoft Edge or Google Chrome, see Appendix C, “Exporting secure
certificates by using the Google Chrome and Microsoft Edge web browsers” on page 147.

Complete the following steps:

1. Open the web browser and connect to the correct URL for the DS8000 system to retrieve
the certificate that you want to export. Figure 9-6 shows the DS8000 login window.

Figure 9-6 DS8000 login window

2. Click the lock next to the URL. A new window opens, as shown in Figure 9-7 on page 107.

106 LDAP Authentication for IBM DS8000 Systems

 Figure 9-7 Secure connection: Firefox

3. Click the arrow on the right. Figure 9-8 shows that the certificate is verified.

Figure 9-8 Certificate verification

Chapter 9. Implementing LDAP through IBM Copy Services Manager 107

 4. Click More Information. Data that is related to the website, privacy, history, and technical
details is shown. Figure 9-9 shows an example.

Figure 9-9 Website Identity abbreviated

5. Click View Certificate. Information that is related to the certificates is displayed. There
also are links to download the PEM (cert) if the HMC is using a self-signed certificate, or to
download the PEM (chain) if the HMC is using a certificate that is signed by a CA.
The file must be downloaded and saved. Figure 9-10 shows a modified view of the
certificate page.

Figure 9-10 PEM certificate and chain

6. Verify that the PEM file successfully downloaded, as shown in Figure 9-11 on page 109.

108 LDAP Authentication for IBM DS8000 Systems

Figure 9-11 Saved PEM files

If you must obtain the certificate for the CSM authentication service from your external CSM
server, use the following URL scheme:
https://my_external_CSM:9562

The browser might present a potential security risk due to a self-signed certificate that is
presented from the CSM server. This behavior is expected, so you can accept the risk for the
connection on port 9562.

The chain file has two or more certificates, and the file must be split with a text editor. Each
file should contain one certificate section, as shown in Example 9-1 on page 105.

Building the truststore file

To build the truststore, you must meet the following requirements:
򐂰 Be able to run the keytool command, which is part of each Java distribution, or the
iKeyman program, which is part of the IBM Java distribution.
򐂰 You need all certificates from the HMC or CSM server and the certificate chain in the
individual files.

After you obtain the certificate files in the PEM format, you must add each individual
certificate to the truststore by running the following command:
keytool -importcert -keystore [truststore_file_name].jks -noprompt -storepass
[tuststore_password] -alias [unique_alias] -file [PEM_FILE]

Important: The alias that is specified in the -alias option must be unique.

When you create the file while adding the first certificate, you are prompted for the password
of the keystore. This password is also required when you import the truststore to the DS8000
system later. Example 9-2 shows a certificate being added to a truststore file.

Example 9-2 Creating and adding the first certificate to the truststore file
% keytool -importcert -keystore myCSM_LDAP_truststore.jks -noprompt -storepass
XXXXXXXXXX -alias r9-hmc1 -file r9-hmc1.pem
Certificate was added to keystore

Run the same keytool command for all the certificate files that you created.

If you try to import a certificate that is already in the keystore, the keytool command issues a
message.

You can use the -list option of the keytool command to display the fingerprints of the
certificates in the keystore:
keytool -list -keystore [truststore_file_name].jks -storepass [tuststore_password]

Chapter 9. Implementing LDAP through IBM Copy Services Manager 109

 Example 9-3 shows how to display the content of your keystore.

Example 9-3 Listing all the keys in the keystore

keytool -list -keystore myCSM_LDAP_truststore.jks -storepass XXXXXXXXXX
Keystore type: jks
Keystore provider: SUN

Your keystore contains four entries

r9-hmc2, MMM DD, YYYY, trustedCertEntry,

Certificate fingerprint (SHA1):
EB:AE:E3:EA:D0:F4:38:DD:68:80:79:BF:9E:45:F4:CD:FC:38:03:E2
interm, MMM DD, YYYY, trustedCertEntry,
Certificate fingerprint (SHA1):
6E:B8:29:1F:E2:E5:11:DC:55:50:6E:1F:16:74:7E:4D:34:71:60:FB
root, MMM DD, YYYY, trustedCertEntry,
Certificate fingerprint (SHA1):
27:E1:A7:9E:34:8B:B1:21:7B:90:B4:2A:C0:7F:1B:F0:08:32:98:5B
r9-hmc1, MMM DD, YYYY, trustedCertEntry,
Certificate fingerprint (SHA1):
69:42:E0:18:C6:E6:D0:8F:31:CA:2B:8B:E2:C3:06:CF:40:44:BF:CB

After you add all the certificates, you create your truststore successfully.

9.4 Configuring the CSM servers for LDAP authentication

You can configure LDAP authentication on a CSM server by using the CSM GUI or the CSM
CLI.

9.4.1 Configuring LDAP by using the CSM GUI

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

From a web browser, open the CSM GUI and run the following commands:
򐂰 For CSM that is embedded on the DS8880 or DS8900 HMC:
https://<HMC_IP_or_FQDN>/CSM/
򐂰 For CSM stand-alone servers:
https://<server_IP_or_FQDN>:9559/CSM/

110 LDAP Authentication for IBM DS8000 Systems

Figure 9-12 shows the CSM GUI login dialog box.

Figure 9-12 CSM GUI login dialog box

After the credentials are authenticated by CSM, select Settings → Administration, and then
click Modify. Figure 9-13 shows an example where we need to provide the following
information.

Figure 9-13 Basic LDAP configuration

򐂰 Authentication method:
– Select Active Directory if you use a Microsoft Active Directory (AD) Server.
– Select LDAP for any other server other than Microsoft AD.
򐂰 Authentication servers
Specify the IP address or server name and the port. For redundancy, specify more than
one server.
򐂰 Bind user ID
Specify the Bind user ID in the full Distinguished Name (DN) format. For Microsoft AD, you
also can specify the userPrincipleName of the Bind user ID.
򐂰 Bind password
The LDAP password for the user that is entered in the Bind User ID field.

Chapter 9. Implementing LDAP through IBM Copy Services Manager 111

 򐂰 Search base for users and groups.
In Figure 2-2 on page 13, the search base is dc=ds8ksme,dc=ibm,dc=com. The search base
instructs CSM to look for users and groups that are stored on any part of the domain
ds8ksme.ibm.com.
򐂰 Enable SSL
You must upload a file that contains all the certificates in PEM / Base64 format. You can
obtain the certificates by using the openssl tool, or you can ask your LDAP administrator
for the certificates, including the certificate chain in PEM format. Then, you can create that
file by using a simple text editor and copying gall certificates into a single file. For more
information, see IBM Knowledge Center.

Figure 9-14 shows the complete configuration dialog box and the Load Certificate button
that you use to upload the certificate text file.

Figure 9-14 Basic LDAP Tab: Completed configuration dialog box

Example 9-4 illustrates the advanced LDAP configuration by using the Advanced tab. If you
must 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 paste it to all the other CSM servers on which you want to have
LDAP configured.

Example 9-4 Advanced LDAP configuration

<server description="IBM Copy Services Manager LDAP Registry">
<ldapRegistry baseDN="DC=ds8ksme,DC=ibm,DC=com"
bindDN="CN=bind,CN=Users,DC=ds8ksme,DC=ibm,DC=com"
bindPassword="{aes}----encrypted-password-here----------"
host="xxxxxx.xxxxx.xx.ibm.com" id="ldapregistry" ignoreCase="true"
ldapType="Microsoft Active Directory" port="636" realm="ldapregistry"
sslEnabled="true" sslRef="ldapsslref">
<failoverServers name="failoverServers">
<server host="xxxxxx.xxxxx.xx.ibm.com" port="636"/>
</failoverServers>
</ldapRegistry>
</server>

112 LDAP Authentication for IBM DS8000 Systems

 Click Test to verify that CSM can communicate with LDAP servers. Figure 9-15 shows a
successful communication.

Figure 9-15 CSM successfully contacts 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. Also, if you use CSM for Copy Services
management, it is ready for LDAP authentication.

Nested group support

Starting with CSM V6.2.10, the CSM authentication server can search in nested group
structures.

To take advantage of this feature, you must add the configuration option
recursiveSearch="true" into the XML structure of the Advanced LDAP configuration tab or
modify ldapregistry.xml on an external CSM server.

For more information, see IBM Knowledge Center.

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

The process for csmcli installation and the initial configuration are described 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 AD server-based authentication.
򐂰 mkldapcfg: Used to configure any LDAP server other than Microsoft AD.

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

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

For more information about this process and each csmcli command, see IBM Knowledge
Center.

Chapter 9. Implementing LDAP through IBM Copy Services Manager 113

 Example 9-5 shows the process of configuring an LDAP server on CSM by using the
command line.

Example 9-5 Configuring an OpenLDAP server on CSM by using the csmcli tool
Enter a username for logging on to the server
csmadmin
Enter a password for logging on to the server
>
IBM Copy Services Manager Command-Line Interface (CLI)
Copyright 2007, 2015 IBM Corporation
CLI Client Version: 6.2.10, Build: a20200915-0935
Authentication file: csmcli-auth.properties

Connected to:
Server: yyyy.yy.ibm.com Port: 9560 UseREST: false
Server Version: 6.2.9.1, Build: a20200804-1704
csmcli> lsauthcfg
IWNR4962W [Oct 20, 2020 7:48:14 AM] No LDAP configuration found.
csmcli> mkldapcfg -server xxx.xx.ibm.com:636;xxx.xx.ibm.com:636 -baseDN
"DC=ds8ksme,DC=ibm,DC=com" -bindDN "CN=bind,DC=ds8ksme,DC=ibm,DC=com" -password
XXXXX -keyfilepath /home/master/cert.txt
IWNR4950I [Oct 20, 2020 7:48:14 AM] Successfully updated the LDAP configuration.
csmcli> lsauthcfg
Server Port Role Type
================================
xxx.xx.ibm.com 636 Primary LDAP
xxx.xx.ibm.com 636 Failover LDAP
csmcli>

9.5 Configuring the DS8000 system for LDAP authentication

To configure the DS8000 system for LDAP authentication, you can use either the DS GUI or
the DS CLI. The LDAP and CSM servers must be running and the CSM servers must be
configured as described in 9.4, “Configuring the CSM servers for LDAP authentication” on
page 110.

9.5.1 Using the DS Storage Manager GUI

To configure the DS8000 LDAP authentication on systems, complete the following steps.
Make sure that you have the latest recommended code running on your DS8880 system
when configuring remote authentication. The following procedure was documented on a
DS8880 system running Licensed Machine Code (LMC) bundle 88.56.9.0.

114 LDAP Authentication for IBM DS8000 Systems

1. Open the DS GUI (https://DS8000_HMC_IP) and log in with an administrative user ID and
password, and then click Log in (Figure 9-16).

Figure 9-16 DS8000 Storage Management login window

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

Figure 9-17 Security settings

3. Select Remote Authentication and click Enable Remote Authentication (Figure 9-18).

Figure 9-18 Remote Authentication option

Chapter 9. Implementing LDAP through IBM Copy Services Manager 115

 4. The Welcome window of the Remote Authentication wizard opens. Click Prerequisites to
display and review the prerequisites for enabling remote authentication. (Figure 9-19).

Figure 9-19 Prerequisites for enabling remote authentication

5. Click Next to open the Authentication Servers tab to enter the authentication servers
configuration, as shown in Figure 9-20.

Figure 9-20 Authentication servers configuration

Enter the following information:

– For Server Host Name, you can add up to two authentication servers that DS8000 can
use for LDAP authentication. The Uniform Resource Identifier (URI) for each
authentication server must be provided. Which URI to use depends on where the CSM
server is installed:
• For an embedded CSM on the DS8000 HMC, use:
https://FQDN_or_IP_of_CSM/CSMAuth/TokenService

Note: Do not specify any port for using an embedded CSM. With HTTPS, the
standard port 443 is used because it is the only allowed port for the embedded
CSM instance.

116 LDAP Authentication for IBM DS8000 Systems

 • For an external CSM server, use:
https://FQDN_or_IP_of_CSM:9562/CSMAuth/TokenService

Note: 9562 is the predefined port for the CSM Authentication Service. This port
might be different in your installation. To verify the correct port, speak to your
CSM admin.

• If you are planning to use embedded and external CSM servers, you might have an
URI that contains the CSM Authentication Service port and one URI without the
port.
– For Truststore File, click the Folder icon to select the truststore file where the CSM
secure certificates are stored. For more information about the truststore file, see 9.3,
“Creating a truststore” on page 102.
– For Truststore Password:
• If you created your truststore file by following the instructions in 9.3.1, “Obtaining
the truststore files for external CSM servers” on page 102, use the passw0rd (with a
zero instead of the letter O) password.
• If you created the truststore file by following the instructions on 9.3.2, “Creating the
truststore files for an embedded CSM server” on page 104, 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.

Note: You can use any existing LDAP user ID for authentication service. However, It
is a best practice to use the same CSM bind user ID that is defined in 9.4.1,
“Configuring LDAP by using the CSM GUI” on page 110. For example, if during the
CSM LDAP configuration you used bind user ID
CN=bind,DC=ds8ksme,DC=ibm,DC=com for the WebSphere User Name, use the user
ID bind.

– For WebSphere Password, enter the password that is defined for the WebSphere
User Name (in our example, it is the password for the LDAP user ID bind).

Chapter 9. Implementing LDAP through IBM Copy Services Manager 117

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

Figure 9-21 Example of a configuration that uses two stand-alone CSM servers for authentication

6. Click Next to display the Authentication Mappings window (Figure 9-22). You must assign
DS8000 roles to the LDAP remote users or groups that you want to grant access to log in
on the DS8000 system.
Click Add Remote Mapping to create an authentication mapping and to select the
DS8000 role that you want to map.

Figure 9-22 Authentication Mappings window

7. In the Create Authentication Mapping window (Figure 9-23 on page 119), complete these
fields:
a. Select the DS8000 user role to be mapped from the Select the user role on the
DS8000 to be mapped menu. If you need detailed information about each DS8000
user role, see Figure 3-5 on page 22.

118 LDAP Authentication for IBM DS8000 Systems

 Note: The secadmin role can be managed only by a DS8000 user that already
belongs to that role (such as the default user secadmin). For more information about
how to map an LDAP user to the Security Administrator role, see 9.6, “Mapping
LDAP users and groups to the DS8000 Security Administrator role” on page 129.

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 system.
d. Click Add. To add new mappings, repeat the steps from this section. For more
information about user groups and roles, see 3.1, “DS8000 basic user management
and access” on page 18.

Figure 9-23 Creating an authentication mapping

Chapter 9. Implementing LDAP through IBM Copy Services Manager 119

 8. Click Next when you complete all the mappings that you need (Figure 9-24).

Figure 9-24 Example of an authentication mapping

9. In the Local Administrator window (Figure 9-25), you can define an existing DS8000 local
administrator that remains active for recovery if the remote authentication servers (LDAP,
CSM, or both) are not available.
Select the Allow checkbox to enable the local administrator feature. Then, select one of
the existing DS8000 local users with the administrator role to be used as the recovery
user. The current password that is configured for the local user that you selected is used.
Therefore, make sure that the correct password is configured before proceeding to the
next steps. After the remote authentication is enabled, you cannot 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 remote authentication mappings.
.

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

Note: As a best practice, use the default local DS8000 admin user as the recovery user
ID (local administrator). Also, note the password.

120 LDAP Authentication for IBM DS8000 Systems

 If you must disable remote authentication on the remote LDAP/CSM servers, you must log
in by using the valid credentials of the recovery user. If you do not have these credentials,
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 cannot connect to the DS8000 system until the reset is performed remotely.

Note: Decide whether you need to map users to the secadmin role by following the
steps in 9.6, “Mapping LDAP users and groups to the DS8000 Security Administrator
role” on page 129.

10.Click Next to display the Administrator Verification window.

11.During the remote authentication activation, the DS8000 system tries to authenticate with
the LDAP server by using the LDAP users that you previously mapped to the Administrator
role (step 7 on page 126) to validate that the configuration is working. In the Administrator
Verification window (Figure 9-26), you must specify one of the LDAP users that you
mapped as a DS8000 administrator and provide its LDAP credentials.
If the LDAP username you 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 9-26 LDAP user that is mapped to the DS8000 Administrator role to be used for verification

Chapter 9. Implementing LDAP through IBM Copy Services Manager 121

 12.Click Next to open the Summary window. Review all the selections (Figure 9-27) before
you finalize the remote authentication setup. Click Back to make changes, if necessary.
Otherwise, click Finish to enable the remote authentication.

Figure 9-27 Configuration summary for remote authentication

If remote authentication was successfully enabled, you get the status “Task completed”,
and the DS GUI automatically disconnects your session, which indicates that the
authentication policy changed (Figure 9-28). The default internal name for the remote
authentication policy that is created by the DS GUI is GUIRemotePolicy.
You can now log in to the DS GUI by using any LDAP user ID that you mapped during the
remote policy configuration.
If you need to add mappings to DS8000 roles, follow the steps in 3.1, “DS8000 basic user
management and access” on page 18.

Figure 9-28 Message that is received when remote authentication is successfully enabled

122 LDAP Authentication for IBM DS8000 Systems

Using the GUI to disable remote authentication
To disable remote authentication and re-enable DS8000 local authentication, complete the
following steps:
1. Log in to the DS GUI (https://DS8000_HMC_IP) by using an external LDAP user that has
DS8000 administrator privileges or use the local DS8000 administrator user ID that you
configured for contingency/recovery. Select Settings → Security → Remote
Authentication (Figure 9-29).

Figure 9-29 Enabling 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 username itself or
any previous local administrator for which you know the credentials).
Click Enable to re-enable the DS8000 local authentication (Figure 9-30).

Figure 9-30 Providing the credentials to enable DS8000 local authentication

Chapter 9. Implementing LDAP through IBM Copy Services Manager 123

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

Figure 9-31 Warning message while enabling DS8000 local authentication

4. If remote authentication is successfully enabled, you see the status “Task completed”, and
the DS GUI automatically disconnects your session with the reason “Authentication Policy
Changed” (Figure 9-32).

Figure 9-32 Concluding the tasks for enabling DS8000 local authentication

You can now log in to the DS GUI by using any valid DS8000 local user.

9.5.2 Configuring DS8000 LDAP authentication by using the DS CLI

Rather than using the DS GUI, you can configure the DS8000 external authentication policy
through the DS CLI by completing the following steps:
1. Open the DS CLI command window and connect to your DS8000 system by 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 9-6. As you can see, the default initialPolicy is set to Basic (local
authentication).

Example 9-6 Listing the authentication policies

dscli> lsauthpol
name type state
==========================
initialPolicy Basic active

124 LDAP Authentication for IBM DS8000 Systems

3. Create an empty policy. Where -type sas specifies the authentication policy type, enter
the mkauthpol -type sas itsopolicy command that is shown in Example 9-7. Currently,
SAS is the only valid value for this parameter, and it is required. Also, itsopolicy defines
the name for the new policy.

Example 9-7 Creating a policy

dscli> mkauthpol -type sas itsopolicy
CMUC00365I mkauthpol: The authentication policy itsopolicy has been created.

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

Example 9-8 Listing of the available policies

dscli> lsauthpol
name type state
============================
initialPolicy Basic active
itsopolicy SAS inactive

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

Example 9-9 Setting the CSM authentication servers

dscli> setauthpol -action setauthserver -loc
https://my_embedded_CSM_on_HMC_1/CSMAuth/TokenService,https://my_embedded_CSM_o
n_HMC_2/CSMAuth/TokenService itsopolicy
CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

For the -loc parameter, you can add up to two authentication servers that the DS8000
system requests for LDAP authentication. The URI for each authentication server should
be provided. Which URI to use depends on where your CSM server is installed:
– If the CSM server is installed on the DS8000 HMC, use the following URI:
https://my_embedded_CSM_on_HMC/CSMAuth/TokenService
– If the CSM server is installed on a stand-alone server, use the following URI:
https://my_external_CSM:9562/CSMAuth/TokenService

Important: If one of your CSM servers is installed on a stand-alone server and one is
installed on the HMC, you must use the corresponding URI. For example:
򐂰 URI for the primary CSM (a stand-alone server):
https://my_external_CSM:9562/CSMAuth/TokenService
򐂰 URI for the secondary CSM (installed on HMC):
https://my_embedded_CSM_on_HMC/CSMAuth/TokenService

The only requirement for this configuration is that you must create the Java truststore
file containing the secure certificates from both CSM servers according to the
procedure in 9.3.2, “Creating the truststore files for an embedded CSM server” on
page 104.

Chapter 9. Implementing LDAP through IBM Copy Services Manager 125

 6. Add the keystore file to the itsopolicy policy. Enter the setauthpol command with the
-action settruststore and -loc parameters, where the value is the location of the
truststore file (see 9.5, “Configuring the DS8000 system for LDAP authentication” on
page 114). Use the -pw parameter for the truststore file password, as shown in
Example 9-10.

Example 9-10 Setting the key

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

itsopolicy
CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

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

Example 9-11 Setting the SAS user

dscli> setauthpol -action setsasuser -username csmldapuser -pw LDAP$3cret
itsopolicy
CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

Note: Although you can use any existing LDAP user ID for authentication, as a best
practice, use the same CSM bind user ID that is defined in 9.4.1, “Configuring LDAP by
using the CSM GUI” on page 110.

For example, if during the CSM LDAP configuration you used 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
system by running the setauthpol -action setmap command with the -extuser or
-extgroup parameters that are associated to the specific DS8000 groups (-dsgroup), as
shown in Example 9-12.

Example 9-12 Mapping a user to a group

dscli> setauthpol -action setmap -extuser lopesle,omarhass -dsgroup admin
itsopolicy
CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

dscli> setauthpol -action setmap -extgroup ldapmonitors -dsgroup monitor

itsopolicy
CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

In Example 9-12, we add 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 mapped to the
DS8000 Monitor role.
For more information about user groups and roles, see 3.3, “Planning for LDAP user
groups and mappings” on page 31.

126 LDAP Authentication for IBM DS8000 Systems

 Note: Decide here whether you need to map users to the secadmin role. Follow the
steps in 9.6, “Mapping LDAP users and groups to the DS8000 Security Administrator
role” on page 129.

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, run the setauthpol command
with the -action setlocaladmin parameter, as shown in Example 9-13.
In this example, the default DS8000 local user admin is configured as the recovery ID.

Example 9-13 Setting the contingency/recovery ID

dscli> setauthpol -action setlocaladmin -username admin -enable itsopolicy
CMUC00366I setauthpol: The authentication policy itsopolicy has been modified.

10.Now the policy is set up but still in inactive state, as shown in Example 9-14.

Example 9-14 Showing the details about the itsopolicy

dscli> showauthpol itsopolicy
name itsopolicy
type SAS
state inactive
location
https://csm01.itso.ibm.com:9562/CSMAuth/TokenService,https://csm02.itso.ibm.com
:9562/CSMAuth/TokenService
truststore itsopolicy_trustStore.jks
sasuser csmldapuser
localAdmin admin

11.Test the configuration by running the testauthpol command and the credentials from one
of the LDAP users that you mapped as a DS8000 administrator in the previous steps, as
shown in Example 9-15.

Example 9-15 Testing the configuration

dscli> testauthpol -username lopesle -pw MySecur3Pas$ itsopolicy
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 completes successfully, you can activate the policy by running the chauthpol
command with the -activate parameter and the credentials from one of the LDAP users
that you mapped as a DS8000 administrator, as shown in Example 9-16.
The basic authentication is inactive, and you see a command execution time-out message
after some time (about 5 minutes). This message is expected, and you must log off from
the DS CLI and reconnect by using the LDAP credentials.

Example 9-16 Activating the itsopolicy

dscli> chauthpol -activate -username lopesle -pw MySecur3Pas$ itsopolicy
CMUC00370W chauthpol: Are you sure that you want to modify the authentication
policy itsopolicy? [y/n]:y
CMUN00015E chauthpol: Command execution timeout

Chapter 9. Implementing LDAP through IBM Copy Services Manager 127

 13.Connect again to the DS CLI by using an LDAP user with the Administrator role and check
the state for the policy by running the lsauthpol command (Example 9-17).

Example 9-17 Listing the available policies

ddscli> lsauthpol
name type state
============================
initialPolicy Basic inactive
itsopolicy SAS active

Disabling the remote authentication policy by using the DS CLI

To disable a remote authentication policy by using the DS CLI, complete the following steps:
1. Open the DS CLI command window and connect to your DS8000 system by using the
credentials from a DS8000 administrator user (or the recovery ID - Local Administrator
feature).
2. To see the existing authentication policies, run the lsauthpol command, as shown in
Example 9-18. In this example, the remote authentication policy GUIRemotePolicy is active
(enabled) and the local authentication policy initialPolicy is inactive (disabled).

Example 9-18 Listing authentication policies

dscli> lsauthpol
name type state
==============================
GUIRemotePolicy SAS active
initialPolicy Basic inactive

3. To disable a remote authentication policy, enable the local authentication (the basic
initialPolicy). Run the chauthpol command with the -activate parameter for the
initialPolicy and provide the credentials from one DS8000 local administrator user, as
shown in Example 9-19. All remote users who are currently logged in are logged out.

Example 9-19 Enabling the local authentication policy

dscli> chauthpol -activate -username admin -pw Adm1nP4S$ initialPolicy
CMUC00370W chauthpol: Are you sure that you want to modify the authentication
policy initialPolicy? [y/n]:y
CMUC00369I chauthpol: The authentication policy initialPolicy has been
modified.

dscli> lsauthpol
name type state
==============================
GUIRemotePolicy SAS inactive
initialPolicy Basic active

128 LDAP Authentication for IBM DS8000 Systems

9.6 Mapping LDAP users and groups to the DS8000 Security
Administrator role
To map any LDAP user or group to the Security Administrator role, complete the following
steps:
1. Make sure that the remote authentication policy that you want to change is disabled
(inactive), as shown in Example 9-20. If it is enabled, any user with Storage Administrator
authority must disable it by using the steps that are detailed in “Disabling the remote
authentication policy by using the DS CLI” on page 128, “Using the GUI to disable remote
authentication” on page 123, and “Disabling the remote authentication policy by using the
DS CLI” on page 128.
2. Open the DS CLI command window and connect to your DS8000 system by using the
credentials from a local DS8000 security administrator user (for example, the default
secadmin user ID).

Tip: The commands cannot run on the embedded DS CLI. You must use an external
DS CLI session.

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

Example 9-20 Listing the available authentication policies

dscli> lsauthpol
name type state
==============================
GUIRemotePolicy SAS inactive
initialPolicy Basic active

4. Map any existing users and user groups from the LDAP server to the DS8000 Security
Administrator group by running the setauthpol -action setmap command with the
-extuser or -extgroup parameters, as shown in Example 9-21.
In this example, the LDAP user ldapsecadminuser is associated to the DS8000 Security
Administrator role.

Example 9-21 Mapping an LDAP user to the DS8000 Security Administrator group
dscli> setauthpol -action setmap -extuser ldapsecadminuser -dsgroup secadmin
GUIRemotePolicy
CMUC00366I setauthpol: The authentication policy GUIRemotePolicy has been
modified.

5. If you must create any extra mappings to the DS8000 Security Administrator role, repeat
step 4. When you have create all the mappings that you need, disconnect from the DS
CLI.
6. Inform your DS8000 Storage Administrator that the remote authentication policy was
changed and that it can be activated. When the storage administrator activates the remote
authentication policy, all the LDAP users that were mapped in step 4 can log in to the
DS8000 system.

Chapter 9. Implementing LDAP through IBM Copy Services Manager 129

130 LDAP Authentication for IBM DS8000 Systems
 A

Appendix A. LDAP planning worksheet

This appendix helps you to collect required data during the planning phase of the DS8000
Lightweight Directory Access Protocol (LDAP) authentication.

Work with your directory server administrator to complete the worksheet before you start the
configuration.

This appendix covers the following topics:

򐂰 Choosing an LDAP implementation
򐂰 Native LDAP
򐂰 Configuring LDAP by using CSM
򐂰 Enabling a local administrator
򐂰 Configuring authentication mappings

© Copyright IBM Corp. 2018, 2021. All rights reserved. 131

Choosing an LDAP implementation
Which authentication method should be implemented?
 Native LDAP authentication (recommended for DS8900 systems on Licensed Machine Code
(LMC) 89.10.92.0 or higher): Continue with “Native LDAP” on page 132.
 LDAP through IBM Copy Services Manager (CSM) (the only method for a DS8880 system):
Continue with “Configuring LDAP by using CSM” on page 134.

Native LDAP
This section describes the following topics:
򐂰 Server details
򐂰 Configuring LDAP servers
򐂰 Configuring the lookup method for the LDAP servers

Server details
 Document your server details in Table A-1.

Table A-1 LDAP server details

LDAP server IP address or fully qualified IP Port for the LDAP service
domain name (FQDN)

LDAP server 1

LDAP server 2

The default port for non-encrypted LDAP is 389, and the default port for encrypted LDAP
(LDAPs) is 636.
 Do you want to have a secured connection between the DS8900 HMC and the LDAP server?
 Yes, I want to secure my connection and I want to retrieve the files.
Ask the LDAP admin for the serial number, Subject Distinguished Name (DN), and the
issuer of each certificate in the certificate chain of the LDAP server. Use Table A-2 to note
the certificate information for the LDAP server certificates.

Table A-2 LDAP server certificate details

Item LDAP server 1 LDAP server 2

Subject DN

Issuer

Serial

You should have one root certificate for the certificate authority (CA) and one intermediate
certificate. Use Table A-3 on page 133 to note the information. Extend the table if you have
more than one intermediate certificate.

132 LDAP Authentication for IBM DS8000 Systems

 Table A-3 Certificate details of certificate chain
Item CA root certificate Intermediate certificate

Subject DN

Issuer

Serial

 Yes, and I want to use a truststore file.

When using a trustfile, you must obtain the certificate of the LDAP server in Privacy
Enhanced Mail (PEM) format and use a keytool to build the truststore. For more
information, see 9.3, “Creating a truststore” on page 102.
 No.

Configuring LDAP servers

 Determine how you want to connect to the LDAP server:
 Anonymous bind
The bind DN or the bind password has a zero length. No user is required to query the
directory.
 Simple bind
A technical user is required to connect to the directory server. Use Table A-4 to note the
bind user details.

Table A-4 Bind user details

Item Bind user details

Bind DN or user ID

Password

 Direct bind
Provide the DN placeholder so that a direct bind can be performed when you enter a user
ID and password. Replace the user ID with {0} or {USERNAME}. Use Table A-5 to note the
DN placeholder details.

Table A-5 DN placeholder

Item DN string

DN placeholder

Configuring the lookup method for the LDAP servers

Note the search base to search Users and Groups in Table A-6. To speed up the search, the
search base might be different.

Table A-6 User and Group Search Base

Item Search base DN

User Search Base

Group Search Base

Appendix A. LDAP planning worksheet 133

 Note the Group Member Attribute of the LDAP user entry in Table A-7. This attribute shows
the groups of which the user is a member of.

Table A-7 Group Member attribute

Item Attribute

Group member attribute

 I am not using a filter. I use the username attribute and group name attribute of the group or
username in the DN part.

Table A-8 Username and Group Name attribute

Item Attribute

Username attribute

Group Name attribute

 I am using an LDAP filter for the Username and Group Name.

Table A-9 Username and Group Name LDAP filter

Item LDAP filter

Username filter

Group Name filter

Continue with “Enabling a local administrator” on page 135.

Configuring LDAP by using CSM

In Table A-10, note your Uniform Resource Identifier (URI) for the CSMAuth service. This URI
is different depending on whether you use an embedded or external CSM.

Table A-10 Scheme of the CSMAuth URI

CSM used URI

Embedded CSM on a https://_embedded_CSM_on_DS8000_HMC_/CSMAuth/TokenService

DS8880 or DS8900
HMC

External CSM https://_external_CSM_:9562/CSMAuth/TokenService

In Table A-11, note in your personalized CSMAuth URI. This URI is different depending on
whether you have an internal or external CSM.

Table A-11 Your CSMAUTH URI

Server IP address / FQDN

Server 1

Server 2

In Table A-12 on page 135, note the location and password of the certificate truststore.

134 LDAP Authentication for IBM DS8000 Systems

 Table A-12 Truststore file
Item Value

File name

Truststore password

In Table A-13, note the CSM user that is mapped from your LDAP server and is a configured
as Admin or User Admin in CSM. This user is used as a kind of bind user between the
DS8000 HMC and CSM.

Table A-13 WebSphere User details

Item Value

IBM WebSphere® username

WebSphere password

Enabling a local administrator

 I do not want to enable a local administrator as a fallback.
 I do want to enable a local administrator ID as a fallback.

Provide the user ID for the local administrator. It must be configured in the initalPolicy.

Table A-14 User ID for the local administrator

Item User ID

Local administrator user ID

Configuring authentication mappings

The following groups must be mapped to an LDAP user or group. Table A-15 provides the
minimum of dsroles that must be mapped to an LDAP user.

You want to have two functional user IDs for IBM Service and IBM Engineering in your LDAP
environment because you must share the passwords on demand for IBM support.

Table A-15 LDAP groups mapped to DS8000 roles

dsrole User / Group Username / Group name

Administrator / admin

Security Administrator
/secadmin

IBM Service

IBM Engineering

Appendix A. LDAP planning worksheet 135

136 LDAP Authentication for IBM DS8000 Systems
 B

Appendix B. Troubleshooting

This appendix provides some guidance about how to troubleshoot obstacles that you might
encounter during the Lightweight Directory Access Protocol (LDAP) remote authentication
configuration. It shows how to verify the parameters that are entered into the GUI or DS
Command-Line Interface (DS CLI).

As a best practice, you should use the following tools:

򐂰 The ldapsearch tool, which is available on most UNIX, Linux, and MacOS platforms
򐂰 The dsquery tool, which is available on Windows platforms

These command-line tools enable a simple but effective query of your directory server.

This appendix covers the following topics:

򐂰 Troubleshooting by using ldapsearch
򐂰 Troubleshooting by using dsquery

© Copyright IBM Corp. 2018, 2021. All rights reserved. 137

Troubleshooting by using ldapsearch
The ldapsearch tool is available on most Linux, UNIX, and MacOS systems. The tool is a
command-line tool. Figure B-1 and Figure B-2 on page 139 show how to transfer the
parameter that you entered into the DS GUI wizard to the command-line tool.

The full man page for ldapsearch can be found at OpenLDAP.

Figure B-1 Using the authentication details in ldapsearch

Figure B-1 shows the first wizard window and a mapping to the parameters that are used with
ldapsearch:
1. Specify the hostname or the IP address of one server that you want to query.
2. When the TLS 1.2 checkbox is selected, specify ldaps in the command to indicate that this
connection is TLS secured.
When the TLS 1.2 checkbox is not selected, specify ldap there.
Ensure that you separate the protocol and the hostname with a colon and two forward
slashes (://).
3. Specify the port. Ensure that you separate the hostname and the port with a colon (:).
4. Depending on the authentication method, specify different values here. Our example is for
a simple bind.
5. Use the Distinguished Name (DN) or the username with the -D command switch.
6. Specify option -w for the password of the user that is specified in step 5.

Figure B-2 on page 139 continues the illustration for assembling the ldapsearch command.

138 LDAP Authentication for IBM DS8000 Systems

Figure B-2 Using the search base and filter in ldapsearch

Figure B-2 shows the search base for the user and groups. In addition, it shows the filters for
the group and usernames.

To complete the ldapsearch command to query a user, complete the following steps:
1. Specify the User search base by using the -b option.
2. Specify the username filter. In our example, we use the attribute uid, but the attribute can
be different in your LDAP server implementation. Replace {0} in the filter string with the
user ID that you want to query.
In addition, you can extend the ldapsearch command with parameters so that you do not
get the full entry. Instead, the command returns only the attributes that are specified. An
example is shown in Example B-2 on page 140.
When you want to use ldapsearch to query a group, you must specify the group
information.
3. Specify the Group search base by using the -b option.
4. Specify the Group name filter and replace {0} in the filter string with the group name that
you want to query. When you want to query all groups or a set of groups, replace {0} with
* or a partial string and *, as shown in Example B-3 on page 141.
5. To see only the members of the group, specify the group membership attribute at the end
of the ldapsearch command.

Appendix B. Troubleshooting 139

 Example B-1 shows the complete entry. Because the entry might be lengthy when you use a
filter that contains a *, you can limit the output to the attributes of interest.

Example: B-1 An ldapsearch example for a complete user entry

ldapsearch -H "ldaps://this-is-my-directory-server.com:636" \
> -D "CN=admin,DC=ds8ksme,DC=ibm,DC=com" \
> -w "Test1234a" \
> -b "DC=ds8ksme,DC=ibm,DC=com" \
> '(&(uid=jdoe)(|(objectclass=Person)(objectclass=posixAccount)))'
# extended LDIF
#
# LDAPv3
# base <DC=ds8ksme,DC=ibm,DC=com> with scope subtree
# filter: (&(uid=jdoe)(|(objectclass=Person)(objectclass=posixAccount)))
# requesting: ALL
#

# jdoe, People, ds8ksme.ibm.com

dn: uid=jdoe,ou=People,dc=ds8ksme,dc=ibm,dc=com
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
loginShell: /bin/false
homeDirectory: /home/jdoe
uid: jdoe
cn: John Doe
uidNumber: 22019
gidNumber: 2118
userPassword:: e1NTSEF9cjR4dnpCWWFQam1TZmJ2RWtsMVpHd3podjdWSFMyTXo=
description: DS8000 Administrator
sn: Doe
givenName: John
mail: [email protected]
employeeNumber: 007

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

In Example B-2, we would like to display only the surname (sn), the user ID (uid), and the
email (mail) information. You can see that the output is much shorter. We extended the
command by using the string sn uid mail. To find out the login name of the user, you can
also specify the log-in attribute that should be used by the user.

Example: B-2 The ldapsearch command shows only a limited number of attributes
ldapsearch -H "ldaps://this-is-my-directory-server.com:636" \
> -D "CN=admin,DC=ds8ksme,DC=ibm,DC=com" \
> -w "Test1234a" \
> -b "DC=ds8ksme,DC=ibm,DC=com" \
> '(&(uid=jdoe)(|(objectclass=Person)(objectclass=posixAccount)))' \

140 LDAP Authentication for IBM DS8000 Systems

> sn uid mail
# extended LDIF
#
# LDAPv3
# base <DC=ds8ksme,DC=ibm,DC=com> with scope subtree
# filter: (&(uid=jdoe)(|(objectclass=Person)(objectclass=posixAccount)))
# requesting: sn uid mail
#

# jdoe, People, ds8ksme.ibm.com

dn: uid=jdoe,ou=People,dc=ds8ksme,dc=ibm,dc=com
uid: jdoe
sn: Doe
mail: [email protected]

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Example B-3 shows a query of all groups whose name starts with the string DS8k_. This query
verifies the correct spelling, including capitalization, of the group name on the LDAP server.

Example: B-3 Showing only LDAP groups starting with DS8k_

ldapsearch -H "ldaps://this-is-my-directory-server.com:636" \
> -D "CN=admin,DC=ds8ksme,DC=ibm,DC=com" \
> -w "Test1234a" \
> -b "OU=group,DC=ds8ksme,DC=ibm,DC=com" \
> '(&(cn=DS8k_*)(objectclass=groupOfNames))' \
cn
# extended LDIF
#
# LDAPv3
# base <OU=group,DC=ds8ksme,DC=ibm,DC=com> with scope subtree
# filter: (&(cn=DS8k_*)(objectclass=groupOfNames))
# requesting: cn
#

# DS8k_Administrator, group, ds8ksme.ibm.com

dn: cn=DS8k_Administrator,ou=group,dc=ds8ksme,dc=ibm,dc=com
cn: DS8k_Administrator

# DS8k_Copy_Services_operator, group, ds8ksme.ibm.com

dn: cn=DS8k_Copy_Services_operator,ou=group,dc=ds8ksme,dc=ibm,dc=com
cn: DS8k_Copy_Services_operator

...

# search result
search: 2
result: 0 Success

# numResponses: 12
# numEntries: 11

Appendix B. Troubleshooting 141

 Example B-4 shows the output of the ldapsearch command that provides the output of all
members of the group DS8k_Administrator. The member attribute shows the DN of all
members in your group so that you can verify whether the group is complete or you are
missing a user. If the members of the group are not all listed, follow your business process to
update the group members.

Example: B-4 The ldapsearch command showing the members of the group DS8k_Administrator
ldapsearch -H "ldaps://this-is-my-directory-server.com:636" \
> -D "CN=admin,DC=ds8ksme,DC=ibm,DC=com" \
> -w "Test1234a" \
> -b "OU=group,DC=ds8ksme,DC=ibm,DC=com" \
> '(&(cn=DS8k_*)(objectclass=groupOfNames))' \
cn member

# DS8k_Administrator, group, ds8ksme.ibm.com

dn: cn=DS8k_Administrator,ou=group,dc=ds8ksme,dc=ibm,dc=com
cn: DS8k_Administrator
member: uid=ppeters,ou=People,dc=ds8ksme,dc=ibm,dc=com
member: uid=jbloggs,ou=People,dc=ds8ksme,dc=ibm,dc=com
member: uid=emusterma,ou=People,dc=ds8ksme,dc=ibm,dc=com
member: uid=jdoe,ou=People,dc=ds8ksme,dc=ibm,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Troubleshooting by using dsquery

The dsquery tool is a command that is available on Microsoft Windows. The program is part of
the Microsoft Active Directory (AD) Domain Services, but it is also available for workstations
in the Remote Server Administration Tools (RSAT). For more information about adding this
feature and other information, see Active Directory doucmentation.

The figures and examples in this section provide a brief overview of the dsquery tool and
show how to get the correct connection information.

142 LDAP Authentication for IBM DS8000 Systems

Figure B-3 shows the first wizard page and a mapping to the parameters that are used with
ldapsearch.

Figure B-3 Using the authentication wizard details with dsquery

The details are as follows:

1. If you do not run dsquery on a Microsoft cluster node, you must specify the -s option and
the Microsoft server to query.
2. You do not need to specify whether the query should be encrypted.
3. You do not need to specify the port number for dsquery.
4. There is no anonymous binding for Microsoft AD by default. You must specify the technical
bind user or a valid user of the domain that you query.
5. Use the -u option to specify the user that you use for the sAMAccountName. You do not
need to specify the userPrincipalName.
6. Use the -p option to specify the password of the user.

The dsquery command can query different objects in the directory. We provide some
examples that help to verify the group and username, and the correct membership of a user.

Appendix B. Troubleshooting 143

 Example B-5 shows dsquery *, which queries every object by using the criteria of an LDAP
query. By using the -filter parameter, we provide the Username search filter that we
entered in the wizard, and by using the -attr * parameter, we print all the attributes of the
entry. This output should be limited to the attributes of interest.

Example: B-5 Using dsquery to query a single user.

dsquery * -s this-is-my-directory-server.com -u itso_admin -p redb00ks -filter
"(&(sAMAccountName=jdoe)(|(objectcategory=user)(objectclass=user)))" -attr *
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: John Doe
sn: Doe
givenName: John
distinguishedName: CN=John Doe,CN=Users,DC=ds8ksme,DC=local
...
displayName: John Doe
uSNCreated: 159287
memberOf: CN=DS8k_Administrator,OU=Groups,DC=ds8ksme,DC=local
uSNChanged: 159306
name: John Doe
...
sAMAccountName: jdoe
...
userPrincipalName: [email protected]
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ds8ksme,DC=local
...

Sometimes, it is necessary to validate the correct spelling of the SAM Account Name of a
group that you want to enter. In Example B-6, we query the groups that are under the group
search base and for which the name starts with DS8k.

Example: B-6 Listing groups in the group search base

dsquery group ou=groups,dc=ds8ksme,dc=local -s this-is-my-directory-server.com -u
bind_user -p Test1234a -o samid -name DS8k*
"DS8k_Administrator"
"DS8k_blocked"
"DS8k_Copy_Services_operator"
"DS8k_IBM_Engineering"
"DS8k_IBM_Service"
"DS8k_Logical_and_copy_operator"
"DS8k_Logical_Operator"
"DS8k_Monitor"
"DS8k_No_Access"
"DS8k_Physical_operator"
"DS8k_Security_Administrator"
"DS8k_Users"

To list all the members of a group, build a query that is assembled out of the dsquery group,
dsget group, and dsget user commands, as shown in Example B-7 on page 145. This
command is lengthy because you must specify the -s, -u, and -p parameter when you cannot
run the command on a Windows client in this domain or on a Microsoft server.

144 LDAP Authentication for IBM DS8000 Systems

Example: B-7 Querying to get the SAM Account Name of a group
dsquery group -samid "DS8k_Administrator" -s this-is-my-directory-server.com -u
bind_user -p Test1234a |dsget group -members -expand -s
this-is-my-directory-server.com -u bind_user -p Test1234a |dsget user -samid -s
this-is-my-directory-server.com -u bind_user -p Test1234a
samid
jdoe
jbloggs
ppieters
emusterma
dsget succeeded

For more enhanced queries and examples, see Active Directory doucmentation, or see Active
Directory: DSQUERY Commands.

Appendix B. Troubleshooting 145

146 LDAP Authentication for IBM DS8000 Systems
 C

Appendix C. Exporting secure certificates by

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

Exporting the DS8000 secure certificates is one of the steps that is required to create the
Java truststore file. This file is used during the configuration of remote authentication on a
DS8000 system. For more information, see 9.3 "Creating a truststore" on 102.

This appendix covers the following topics:

򐂰 Exporting a certificate on Microsoft Edge
򐂰 Exporting a certificate on Google Chrome

© Copyright IBM Corp. 2018, 2021. All rights reserved. 147

Exporting a certificate on Microsoft Edge
To export secure certificates by using Microsoft Edge, complete the following steps:
1. Open the Edge browser and connect to the DS8000 HMC by using the correct URL for the
secure certificates that you want to export.
2. Regardless of the secure certificate URL that you use, click the lock to the left of the URL
to display the website information (Figure C-1).

Figure C-1 DS8000 login window by using Microsoft Edge

3. In the Website identification window (Figure C-2), click View certificate.

Figure C-2 Website identification

148 LDAP Authentication for IBM DS8000 Systems

 4. The Certificate Information window opens. Select the Root CA and then Export to file
(Figure C-3). Save the certificate.

Figure C-3 DS8000 root certificate

5. Repeat step 4 for the intermediate certificate.

The export process is now complete. Figure C-4 shows the saved certificates.

Figure C-4 Saved DS8000 certificate

Exporting a certificate on Google Chrome

To export the DS8000 secure certificates by using the Google Chrome web browser,
complete the following steps:
1. Open the Google Chrome browser and connect to the DS8000 HMC by using the correct
URL for the secure certificates that you want to export.

Appendix C. Exporting secure certificates by using the Google Chrome and Microsoft Edge web browsers 149
 2. Regardless of the secure certificate URL that you are using, click the Customize and
control Google Chrome icon (the three vertical dots to the right of the URL), and then
select More tools → Developer tools (Figure C-5).

Figure C-5 Opening the Chrome Developer tools

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

Figure C-6 Viewing the DS8000 secure certificate

150 LDAP Authentication for IBM DS8000 Systems

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

Figure C-7 Details of a DS8000 secure certificate

5. The Certificate Export wizard starts. Click Next (Figure C-8).

Figure C-8 Certificate Export Wizard

Appendix C. Exporting secure certificates by using the Google Chrome and Microsoft Edge web browsers 151
 6. In the Export File Format window, select Base-64 encoded X.509 (.CER) and click Next
(Figure C-9).

Figure C-9 Export File Format

7. 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
(Figure C-10).

Figure C-10 File to export window

152 LDAP Authentication for IBM DS8000 Systems

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

Figure C-11 Summary of the certificate export wizard

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

Figure C-12 Conclusion of export process

Appendix C. Exporting secure certificates by using the Google Chrome and Microsoft Edge web browsers 153
154 LDAP Authentication for IBM DS8000 Systems
Related publications

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

IBM Redbooks
The following IBM Redbooks publications provide more information about the topics in this
document. Some publications that are referenced in this list might be available in softcopy
only.
򐂰 DS8000 Copy Services, SG24-8367
򐂰 IBM DS8000 Encryption for data at rest, Transparent Cloud Tiering, and Endpoint Security
(DS8000 Release 9.0), REDP-4500
򐂰 IBM DS8900F Architecture and Implementation Release 9.1, SG24-8456

You can search for, view, download, or order these documents and other Redbooks,
Redpapers, web docs, drafts, and additional materials, at the following website:
ibm.com/redbooks

Online resources
These websites are also relevant as further information sources:
򐂰 DS8000 Series Copy Services Fibre Channel Extension Support Matrix:
http://www.ibm.com/support/docview.wss?uid=ssg1S7003277
򐂰 IBM Disk Storage Feature Activation (DSFA), found at:
http://www.ibm.com/storage/dsfa
򐂰 IBM Fix Central:
https://www.ibm.com/support/fixcentral/swg/selectFixes?parent=Enterprise%20Stor
age%20Servers&product=ibm/Storage_Disk/DS8900F
򐂰 IBM Knowledge Center: DS8000:
https://www.ibm.com/support/knowledgecenter/SSHGBU
򐂰 IBM System Storage Interoperation Center (SSIC), found at:
http://www.ibm.com/systems/support/storage/config/ssic/index.jsp

© Copyright IBM Corp. 2018, 2021. All rights reserved. 155

Help from IBM
IBM Support and downloads
ibm.com/support

IBM Global Services

ibm.com/services

156 LDAP Authentication for IBM DS8000 Systems

Back cover

REDP-5460-01

ISBN 0738459488

Printed in U.S.A.

®
ibm.com/redbooks