Dell PowerStore

Security Configuration Guide

Version 4.x

May 2024
Rev. A12
Notes, cautions, and warnings

NOTE: A NOTE indicates important information that helps you make better use of your product.

CAUTION: A CAUTION indicates either potential damage to hardware or loss of data and tells you how to avoid
the problem.

WARNING: A WARNING indicates a potential for property damage, personal injury, or death.

© 2020 - 2024 Dell Inc. or its subsidiaries. All rights reserved. Dell Technologies, Dell, and other trademarks are trademarks of Dell Inc. or its
subsidiaries. Other trademarks may be trademarks of their respective owners.
 Contents

Additional Resources.....................................................................................................................6
Legal disclaimers.................................................................................................................................................................. 6
Reporting security vulnerabilities.....................................................................................................................................6
Follow us online.................................................................................................................................................................... 6
Dell security advisories....................................................................................................................................................... 7
False positive security vulnerabilities.............................................................................................................................. 7

Chapter 1: Overview...................................................................................................................... 8
Introduction to PowerStore ............................................................................................................................................. 8
Points of administrative access....................................................................................................................................... 8
Code signing......................................................................................................................................................................... 8
Hardware root of trust....................................................................................................................................................... 8

Chapter 2: Physical Security........................................................................................................10

Physical security controls ............................................................................................................................................... 10
Port security ...................................................................................................................................................................... 10

Chapter 3: PowerStore Manager.................................................................................................. 11

PowerStore Manager checklist....................................................................................................................................... 11
Authenticating and managing user accounts, roles, and privileges....................................................................... 12
Factory default management.................................................................................................................................... 12
Session rules..................................................................................................................................................................13
Username and password usage................................................................................................................................ 13
Configuring RSA SecurID authentication............................................................................................................... 14
Roles and privileges..................................................................................................................................................... 19
User account management based on role privileges.......................................................................................... 23
Login message..............................................................................................................................................................29
Reset admin and service account passwords.......................................................................................................29
Certificates.......................................................................................................................................................................... 31
Viewing certificates..................................................................................................................................................... 31
Signed cluster certificate.......................................................................................................................................... 32
Secure communication between PowerStore appliances within a cluster..........................................................42
Secure communication for replication and data import........................................................................................... 42
VASA certificate................................................................................................................................................................ 42
Generate a Certificate Signing Request................................................................................................................ 43
Import a third party Certificate Authority signed server certificate for VASA Provider........................... 43
vSphere Storage API for Storage Awareness support.............................................................................................44
iSCSI CHAP authentication.............................................................................................................................................46
Configuring CHAP....................................................................................................................................................... 46
External SSH access.........................................................................................................................................................47
Configuring external SSH access............................................................................................................................ 47
NFS secure......................................................................................................................................................................... 48
Security on file system objects...................................................................................................................................... 49
File systems access in a multiprotocol environment................................................................................................ 50

Contents 3
 User mapping............................................................................................................................................................... 50
Access policies for NFS, SMB, and FTP................................................................................................................53
Credentials for file level security............................................................................................................................. 54
Data protection with secure snapshots.......................................................................................................................55
Communication between PowerStore and a Metro Witness................................................................................. 56
Generating a Metro Witness secure token........................................................................................................... 56
Retrieving a Metro Witness thumbprint for validation.......................................................................................56
Port usage........................................................................................................................................................................... 57
Appliance network ports............................................................................................................................................ 57
Appliance network ports related to file..................................................................................................................59
HTTP redirect to HTTPS.................................................................................................................................................62
Configuring HTTP Redirect to HTTPS...................................................................................................................63
Auditing................................................................................................................................................................................63
Remote logging.................................................................................................................................................................. 63
Add Remote Syslog Server....................................................................................................................................... 64
Import a certificate for remote logging..................................................................................................................65
Generate a Certificate Signing Request................................................................................................................ 65
Manage remote logging settings............................................................................................................................. 66
Operational description of Support Connectivity...................................................................................................... 67
Support Connectivity enablement precheck.........................................................................................................67
Support Connectivity and security..........................................................................................................................67
Support Connectivity management........................................................................................................................ 68
Support Connectivity communication.................................................................................................................... 68
Support Connectivity remote support................................................................................................................... 68
Support Connectivity options........................................................................................................................................ 68
Support Connectivity using the Secure Connect Gateway option................................................................. 69
Requirements for Support Connectivity using the Secure Connect Gateway.............................................69
Support Connectivity using the Connect Directly option..................................................................................69
Requirements for Support Connectivity using Connect Directly.....................................................................70
Configuring Support Connectivity.................................................................................................................................70
Configure the initial setup of Support Connectivity........................................................................................... 70
Manage Support Connectivity settings..................................................................................................................72
CloudIQ................................................................................................................................................................................ 73
Cybersecurity..................................................................................................................................................................... 73
Alert settings...................................................................................................................................................................... 73
Configure email notifications.................................................................................................................................... 74
Configure SNMP..........................................................................................................................................................75
Common Event Enabler Common Event Publishing Agent..................................................................................... 76
Understanding the Common AntiVirus Agent (CAVA).............................................................................................76
Malware detection............................................................................................................................................................ 76

Chapter 4: Data at Rest Encryption............................................................................................. 77

Data at Rest Encryption...................................................................................................................................................77
Encryption activation........................................................................................................................................................77
Encryption status...............................................................................................................................................................77
Key management............................................................................................................................................................... 78
Keystore backup file......................................................................................................................................................... 78
External key management............................................................................................................................................... 78
Generate a Certificate Signing Request................................................................................................................ 80
Import a certificate for KMIP................................................................................................................................... 80

4 Contents
 Enable KMIP server configuration............................................................................................................................81
Manage KMIP settings................................................................................................................................................81
Repurpose a drive in an appliance with encryption enabled................................................................................... 82
Replacing a base enclosure and nodes from a system with encryption enabled............................................... 83
Resetting an appliance to factory settings................................................................................................................. 83

Chapter 5: Federal and DoD Standards and Compliance............................................................... 84

Transport Layer Security.................................................................................................................................................84
STIG......................................................................................................................................................................................84
Enable STIG ................................................................................................................................................................. 84
User account settings when STIG is enabled.......................................................................................................86
FIPS...................................................................................................................................................................................... 87

Appendix A: TLS cipher suites..................................................................................................... 88

Supported TLS cipher suites.......................................................................................................................................... 88

Contents 5
 Preface

As part of an improvement effort, revisions of the software and hardware are periodically released. Some functions that are
described in this document are not supported by all versions of the software or hardware currently in use. The product release
notes provide the most up-to-date information about product features. Contact your service provider if a product does not
function properly or does not function as described in this document.
NOTE: PowerStore X model customers: For the latest how-to technical manuals and guides for your model, download the
PowerStore 3.2.x Documentation Set from the PowerStore Documentation page at dell.com/powerstoredocs.

Where to get help

Support, product, and licensing information can be obtained as follows:
● Product information—For product and feature documentation or release notes, go to the PowerStore Documentation
page at dell.com/powerstoredocs.
● Troubleshooting—For information about products, software updates, licensing, and service, go to Dell Support and locate
the appropriate product support page.
● Technical support—For technical support and service requests, go to Dell Support and locate the Service Requests
page. To open a service request, you must have a valid support agreement. Contact your Sales Representative for details
about obtaining a valid support agreement or to answer any questions about your account.

Legal disclaimers
THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS-IS." DELL MAKES NO REPRESENTATIONS OR
WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY
DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. In no event
shall Dell Technologies, its affiliates or suppliers, be liable for any damages whatsoever arising from or related to
the information contained herein or actions that you decide to take based thereon, including any direct, indirect,
incidental, consequential, loss of business profits or special damages, even if Dell Technologies, its affiliates or
suppliers have been advised of the possibility of such damages.
The Security Configuration Guide intends to be a reference. The guidance is provided based on a diverse set of installed systems
and may not represent the actual risk/guidance to your local installation and individual environment. It is recommended that all
users determine the applicability of this information to their individual environments and take appropriate actions. All aspects of
this Security Configuration Guide are subject to change without notice and on a case-by-case basis. Your use of the information
contained in this document or materials linked herein is at your own risk. Dell reserves the right to change or update this
document in its sole discretion and without notice at any time.

Reporting security vulnerabilities

Dell takes reports of potential security vulnerabilities in our products very seriously.
For the latest on how to report a security issue to Dell, see the Dell Vulnerability Response Policy on the Dell.com site.

Follow us online
Follow Dell Technologies Security on these sites:
● dell.com/security
● dell.com/support
Dell Technologies and the authors of this document welcome your feedback on the solution documentation. Contact Dell
Technologies Solutions Team with your comments.
To provide feedback on this solution, email us at [email protected].

6 Additional Resources
Dell security advisories
Dell Security Advisories (DSAs) notify customers about potential security vulnerabilities and their remedies for Dell Technologies
products. The advisories include specific details about an issue and instructions to help prevent or alleviate that security
exposure.
Common Vulnerabilities and Exposures (CVEs) identify publicly known security concerns. A DSA can address one or more CVEs.
Dell Support site for security contains a list of all PowerStore DSAs, together with the CVEs that they address.

False positive security vulnerabilities

It is possible for a security scan to incorrectly identify a CVE as affecting a Dell Technologies product. CVEs in this category are
termed false positives.
You can find false positives for PowerStore in Knowledge Base (KB) articles for the associated PowerStore software versions at
the Dell Support site.

Additional Resources 7
 1
Overview
This chapter contains the following information:
Topics:
• Introduction to PowerStore
• Points of administrative access
• Code signing
• Hardware root of trust

Introduction to PowerStore
PowerStore achieves new levels of operational simplicity and agility, uses a container-based microservices architecture,
advanced storage technologies, and integrated machine learning to unlock the power of your data. PowerStore is a versatile
platform with a performance-centric design that delivers multidimensional scale, always on data reduction, and support for
next generation media. It brings the simplicity of public cloud to on-premises infrastructure, streamlining operations with an
integrated machine learning engine and nondisruptive automation, while offering predictive analytics to monitor, analyze, and
troubleshoot the environment. PowerStore is also highly adaptable. It provides the flexibility to host specialized workloads
directly on the appliance and modernize infrastructure without disruption, all while offering investment protection through
flexible payment solutions and data-in-place upgrades.
PowerStore T and PowerStore Q appliance models are storage-centric, and enable you to manage and provision block and file
storage to external hosts. During initial configuration, you can choose to configure an appliance for unified (block and file) or
block optimized (block-only) storage. See the PowerStore Simple Support Matrix document at dell.com/powerstoredocs for a
list of the PowerStore appliance models that are available for deployment.

Points of administrative access

The points of administrative access to a PowerStore appliance are:
● Direct access to the physical system
● Through the PowerStore Manager web-based application on a PowerStore appliance.
The following points of administrative access must be secured in a PowerStore appliance:
● Physical: Physical security includes limiting who has access to the data center and appliance hardware. It also includes
monitoring port access under normal and service operations.
● PowerStore Manager: A web-based application that enables you to quickly and easily provision, manage, and monitor
PowerStore clusters.

Code signing
PowerStore is designed to accept software upgrades for both new releases and patch releases. A master GNU Privacy
Guard (GPG) key signs all PowerStore software packages and Dell controls this GPG key. The PowerStore software upgrade
process verifies the signature of the software package, and rejects invalid signatures that might indicate possible tampering or
corruption. The verification step is built into the upgrade process, and the signature of the software package is automatically
verified during the pre-installation phase.

Hardware root of trust

NOTE: Applicable to the following PowerStore models:

8 Overview
 ● 500T
● 1200T
● 3200T
● 5200T
● 9200T
The PowerStore hardware provides the following security features for firmware images and the operating system through the
Secure Boot and x86 Secure Boot technologies that are provided through the enclosure management software on the system:
● Authentication and root of trust provides the capability to authenticate boot loader and firmware, and immutable hardware
root of trust.
● Ensure a verified and measured boot.
● Authenticate firmware images and operating system boot loader at boot time.
● Digitally signed firmware upgrades ensure that root of trust authenticates all signed upgrade firmware images.

Overview 9
 2
Physical Security
This chapter describes physical security controls that you should put in place to ensure a secure environment.
Topics:
• Physical security controls
• Port security

Physical security controls

The area where the storage system resides must be chosen and modified to provide for the physical security of the storage
system. These include basic measures such as providing sufficient doors and locks, permitting only authorized and monitored
physical access to the system, providing reliable power source, and following standard cabling best practices.
In addition, the password reset button requires particular care. It temporarily resets the factory default passwords for both the
appliance default administrator account and service account - until an administrator resets the password.

Port security
A PowerStore appliance includes several physical ports. Ensure that only authorized personnel have access to the ports and that
they are used for their intended purpose.

10 Physical Security
 3
PowerStore Manager
This chapter contains the following information:
Topics:
• PowerStore Manager checklist
• Authenticating and managing user accounts, roles, and privileges
• Certificates
• Secure communication between PowerStore appliances within a cluster
• Secure communication for replication and data import
• VASA certificate
• vSphere Storage API for Storage Awareness support
• iSCSI CHAP authentication
• External SSH access
• NFS secure
• Security on file system objects
• File systems access in a multiprotocol environment
• Data protection with secure snapshots
• Communication between PowerStore and a Metro Witness
• Port usage
• HTTP redirect to HTTPS
• Auditing
• Remote logging
• Operational description of Support Connectivity
• Support Connectivity options
• Configuring Support Connectivity
• CloudIQ
• Cybersecurity
• Alert settings
• Common Event Enabler Common Event Publishing Agent
• Understanding the Common AntiVirus Agent (CAVA)
• Malware detection

PowerStore Manager checklist

The following checklist summarizes the security-related tasks that you should perform to improve the security of your
deployment.

Table 1. PowerStore Manager security configuration checklist

Purpose of activity Task
Access control

Authenticate users with a user account stored on an LDAP- Set up LDAP-SSL authentication.
SSL (LDAPS) server.
User-based access control

Restrict the management operations users can perform. Assign users the minimum access that they require.
Certificate files

PowerStore Manager 11
Table 1. PowerStore Manager security configuration checklist (continued)
Purpose of activity Task
Replace default certificates with customer-supplied Replace pregenerated SSL certificates.
certificates for secure communications.

Authenticating and managing user accounts, roles,

and privileges
Authentication for access to the cluster is performed based on the credentials of a user (local or LDAP) account. User
accounts are created and then managed from the PowerStore Users page, which is accessible in PowerStore Manager
through Settings > Security > Users. The authorizations that apply depend on the role that is associated with the user
account. When the user specifies the network address of the cluster as the URL in a web browser, the user is presented with a
login page from which the user can authenticate as either a local user or through an LDAP directory server. The credentials that
the user provides will be authenticated, and a session will be created on the system. Then, the user can monitor and manage the
cluster within the capabilities of the role that is assigned to the user. The cluster authenticates its users by validating usernames
and passwords through a secure connection with the management server.
NOTE: If a user with an Active Directory (AD) account is a member of the Protected Users Security Group, LDAP
authentication will fail when that user attempts to log in to PowerStore. Do not add a user to the Protected Users Security
Group if that user will be used to log in to PowerStore.
The Lightweight Directory Access Protocol (LDAP) is an application protocol for querying directory services running on
TCP/IP networks. LDAP provides central management of authentication and identity and group information that is used for
authorization on the cluster. Integrating the system into an existing LDAP environment provides a way to control user and user
group access to the system through PowerStore Manager, RESTful API, or CLI.
After you configure LDAP settings for the system, you can manage users and user groups, within the context of an
established LDAP directory structure. For instance, you can assign access roles (Administrator, Storage Administrator, Security
Administrator, Operator, VM administrator) to the LDAP user or groups. The role that is applied determines the level of
authorization the user or group has in administering the storage system. The system uses the LDAP settings only for facilitating
control of access to PowerStore Manager, RESTful API, or CLI, not for access to storage resources.
NOTE: When users attempt to perform an action in PowerStore Manager for which they are not authorized, a notification
appears stating that the action is not authorized.

Factory default management

Your appliance comes with factory default user account settings to use when initially accessing and configuring the appliance.
During initial configuration, the default passwords must be changed so that the system can become fully operational. The
password change is set before the cluster is created.
NOTE: With releases 1.0.x, it is recommended that you initially configure PowerStore using PowerStore Manager rather
than using the API, CLI, or Service Scripts interfaces. It ensures that all the default passwords are changed. With releases
2.x, the default passwords must be changed during initial configuration, however, the API, CLI, or Service Scripts interfaces
can be used as well as PowerStore Manager.

Table 2. Factory default user account settings

Account type Username Password Privileges
System management admin Password123# Administrator privileges are used to reset default
passwords, configuring appliance settings, and
managing user accounts.
Service service service Used to perform service operations.
NOTE: The service user exists for secure
shell (SSH) access. However, you cannot
log in to PowerStore Manager using
the service user. With release 3.6.1 and

12 PowerStore Manager
Table 2. Factory default user account settings (continued)
Account type Username Password Privileges

later, the svc_pstcli service script

enables service users to run PowerStore
CLI commands with certificate-based
authentication instead of username- and
password-based authentication. Certificate-
based authentication gives a service account
user operator role CLI option. For more
information about the svc_pstcli service
script, see the PowerStore Service Scripts
Guide.

Session rules
Sessions on the cluster have the following characteristics:
● Expiration term of one hour.
NOTE: User is automatically logged off the cluster after session inactivity of one hour.
● The session timeout is not configurable.
NOTE: When STIG is enabled in a PowerStore cluster, the behavior of the session time out changes. All account
sessions that existed at the time of STIG enablement will be automatically expired. Those users will be prompted to
change their password to meet the new policy. The session idle timeout for local users will change from a fixed 60
minutes to the default of 10 minutes. If necessary, the default session idle time out can be changed to either 5 or
20 minutes by a user with Administrator or Security Administrator privilege by using either PowerStore Manager or
the REST API, security_config. Linux service users have a fixed session idle timeout of 10 minutes. For more
information about the REST API, see the PowerStore REST API Reference Guide.

Username and password usage

NOTE: The appliance does not manage LDAP user passwords. LDAP user password management is performed on the LDAP
directory server.
System account usernames must meet the following requirements:

Table 3. Username requirements

Restriction Username requirement
Structure Must start and end with an alphanumeric character.
Case All usernames are case-insensitive.
Minimum number of alphanumeric characters 1
Maximum number of alphanumeric characters 64
Supported special characters . (dot)

System account passwords must meet the following requirements:

Table 4. Password requirements

Restriction Password requirement
Minimum number of characters 8
Minimum number of uppercase characters 1
Minimum number of lowercase characters 1

PowerStore Manager 13
Table 4. Password requirements (continued)
Restriction Password requirement
Minimum number of numeric characters 1
Minimum number of special characters 1
● Supported characters: ! @ # $ % ^ * _ ~ ?
NOTE: The password cannot include single quote ('),
ampersand (&), or space characters.

Maximum number of characters 40

NOTE: The last five passwords are blocked from being reused. A previous password can be reused after the fifth time in
sequence. When STIG is enabled, users are required to change their password based on the following STIG new password
policy rules:
● Password length should be a minimum of 15 characters.
● At least 8 characters must be different from the prior password.
● A local user password expires after 60 days by default.
NOTE: This rule does not apply to the default admin and service user passwords. Those passwords do not expire.
● The lifetime for user passwords is a minimum of 1 day.
NOTE: This rule does not apply to the default admin and service users.

Configuring RSA SecurID authentication

RSA SecurID authentication provides an additional layer of security when logging in to or performing transactions through
PowerStore Manager. It is a core component of a strong identity and access management policy.
PowerStore must be connected to a customer-supplied server running RSA Authentication Manager to configure RSA SecurID.
The RSA SecurID configuration can be enabled, disabled, reenabled, and deleted.
RSA Authentication Manager is an application that PowerStore integrates with to perform token-based authentication.
RSA Authentication Manager is the authentication, administration, and database management component of RSA SecurID.
PowerStore supports RSA Authentication Manager versions 8.5 and 8.6.
Users that log in to PowerStore Manager while RSA SecurID is enabled are required to enter a password. They must also
authenticate using their passcode from one of the following:
● RSA hard token – Physical device that shows a generated passcode for the user.
● RSA soft token – Application that is used to generate a passcode for the user.
RSA SecurID validates the identity of the user before the user is allowed access to a PowerStore cluster through PowerStore
Manager. See RSA SecurID authentication objects and process.

14 PowerStore Manager
Figure 1. RSA SecurID authentication objects and process

Table 5. RSA SecurID authentication objects and processing

Item Description
1 A user logs in to PowerStore Manager on client browser host.
NOTE: The user must provide the local user password first. Once PowerStore Manager successfully
verifies the password, the user must enter the RSA passcode.

2 PowerStore Manager for PowerStore version 3.5

3 PowerStore Manager communicates with the RSA Authentication Manager to verify the RSA passcode.
4 RSA Authentication Manager
5 RSA Authentication Manager responds with Success or Fail.

Administrators can choose to bypass some users from RSA SecurID authentication. By default, the Bypass User setting is not
selected for RSA SecurID authentication for all local user accounts. This setting is configurable and can be applied to a local user
account even when RSA SecurID authentication is not enabled. LDAP user or group accounts, if used, cannot be bypassed from
RSA SecurID authentication.

NOTE: If RSA SecurID authentication is not required, users must still authenticate using a password.

General RSA SecurID restrictions and limitations

The following restrictions and limitations apply to RSA SecurID:
● The service user account does not support RSA SecurID authentication. A service user uses username and password
authentication.

PowerStore Manager 15
● LDAP user or group accounts, if used, cannot be bypassed from RSA SecurID authentication.
● RSA SecurID enabled user accounts cannot be used to establish VASA or remote systems connections for replication.

Workflow to set up RSA SecurID

Use the following workflow to set up RSA SecurID for PowerStore Manager:
1. In PowerStore Manager, add a user account with Bypass MFA selected if one does not already exist.
NOTE: This action is recommended, though not required, and ensures that at least one user will have access to
PowerStore Manager and not get locked out based on RSA SecurID. The svc_mfa_state service command can be
used in case of lockout. For information about service commands, see PowerStore Service Scripts Guide.
2. Using the SecurID Security Console of the RSA Authentication Manager, do the following:
NOTE: For more detailed information about the following items, see the related RSA SecurID documentation:
● RSA Authentication Manager
● SecurID Security Console
● RSA SecurID tokens
○ Assigning a token
○ Managing Software Token Profiles
○ Distributing a token
a. Add PowerStore as a new Authentication Agent.
NOTE: Use the PowerStore cluster management IP address to resolve the PowerStore hostname (FQDN cluster
name).
b. Locate and copy the RSA Authentication Manager Access Key for the RSA SecurID Authentication API from the
Authentication Settings of the Setup System Settings.
NOTE: The Access Key is needed later when you configure RSA SecurID in PowerStore Manager.
c. Locate and export the RSA Authentication Manager Certificate Authority (CA) certificate.
NOTE: Download the certificate file (filename.cer in Base64-encoded ASCII) or copy the certificate text to a local
computer. The certificate is needed later when you configure RSA SecurID in PowerStore Manager.
d. Identify and add the PowerStore Local users that are not bypassed to the list of Existing Users on the RSA
Authentication Manager.
NOTE: Use the MFA alias name of the local users from the PowerStore cluster as the User ID on the RSA
Authentication Manager.
e. Assign an available SecurID token to the PowerStore user.
NOTE: The available tokens can be found on the unassigned tokens tab on the RSA Authentication Manager.
3. In PowerStore Manager, configure RSA SecurID for the PowerStore cluster.
a. Configure the RSA SecurID server settings.
NOTE: The Client ID must match what was configured earlier on the RSA Authentication Manager for the RSA
Authentication Agent name. Paste the RSA Authentication Manager Access Key for the RSA SecurID Authentication
API that was copied earlier from the RSA Authentication Manager.
b. Add the RSA Authentication Manager CA certificate that was previously exported.
c. Select users to bypass SecurID authentication.
NOTE: It is recommended, though not required, that at least one user with the admin or security admin role bypass
SecurID authentication. The svc_mfa_state service command can be used in case of lockout. For information
about service commands, see PowerStore Service Scripts Guide.
d. Enable RSA SecurID.
4. Using the SecurID Security Console of the RSA Authentication Manager, distribute the token that was assigned earlier to the
PowerStore user.
NOTE: Download the token file and copy it to the locations where the SecurID application resides.

16 PowerStore Manager
Set up the RSA SecurID configuration on PowerStore
Prerequisites
RSA SecurID is not already configured. The RSA SecurID settings page only shows the Configure control.
Users have RSA soft or hard token licenses.
For LDAP users, LDAP must be configured.
NOTE: It is recommended, though not required, that at least one user with the Administrator or Security Administrator role
bypass SecurID authentication. This administrator will have access to the system if an issue occurs with the RSA SecurID
Authentication Manager. Also, as the current user, you cannot bypass yourself. In this case, an additional account is needed.
PowerStore must be connected to a customer-supplied server running RSA Authentication Manager version 8.5 or 8.6.
NOTE: This includes performing the following tasks using the SecurID Security Console of the RSA Authentication
Manager:
● Adding PowerStore as a new Authentication Agent
● Copying the RSA Authentication Manager Access Key for the RSA SecurID Authentication API
● Exporting the RSA Authentication Manager Certificate Authority (CA) certificate
● Identifying and adding the PowerStore system as a new user to the list of existing users
● Assigning an unassigned SecurID token to the PowerStore user
For more details about these tasks, see Workflow to set up RSA SecurID.

About this task

To set up the RSA SecurID configuration, do the following:

Steps
1. Select the Settings icon, and then select Authentication in the Security section.
2. If not already selected, select RSA SecurID.
3. Click Configure.
The Configure Authentication wizard appears and shows the RSA SecurID Server Settings that must be configured.
4. Fill in the RSA SecurID Server Settings information:
a. Type in the Server IP address or FQDN of the RSA SecurID server.
NOTE: The FQDN to IP address mapping must be registered on the DNS server or servers that the PowerStore
cluster uses to resolve FQDNs into IP addresses.

b. The Port field is already populated with default port 5555 for the RSA SecurID server. If a different port other than the
default port will be used, either type in the new port number or use the up/down control to select the port.
NOTE: If a different port for the RSA SecurID server will be used other than the default port 5555, ensure that the
new port is open for network traffic.

c. Type in the Client ID.

NOTE: The Client ID must be the same as that configured on the RSA Authentication Manager.

d. Copy and paste the Access Key from the RSA Authentication Manager.
e. Click Next.
5. To import the RSA SecurID CA certificate, do one of the following:
NOTE: The CA certificate may be configured on the RSA SecurID server, or a third-party CA may be used. The FQDN or
IP address must be in the SubjName or SubjAltName attribute of the RSA SecurID CA certificate.

● Select Select Certificate File, and locate and select the CA certificate file. Click Next.
● Select Paste Certificate Text, and copy and paste the CA certificate text into the text box. Click Next.
6. Select users to bypass SecurID authentication.

PowerStore Manager 17
 NOTE: All LDAP users and all local users that are not explicitly selected for bypass must supply a SecurID passcode
when logging into PowerStore Manager. Users of any role can be bypassed. Also, the following accounts must be
bypassed:
● The account or accounts used for replication configuration
● Any account used for external applications
● The account used for emergency access when the RSA SecurID server is unavailable

7. After all the bypass users have been selected, click Next.
8. For Enablement, do one of the following:
● Select Enable SecurID to configure SecurID as initially enabled.
NOTE: If Enable SecurID is selected, a message is shown to the user that their browser session will terminate
immediately upon successful completion of the configuration.
● Select Enable SecurID later manually in Settings page to configure SecurID as initially disabled.
9. Click Next.
If the user selected Enable SecurID, the Summary page is the last page they will see, as their session will be terminated. If
the user selected Enable SecurID later manually in Settings page, the user will see a success message.
10. Click Done to exit the configuration wizard.

Manage RSA SecurID information

Prerequisites
RSA SecurID must be initially configured before you can manage the RSA SecurID information.

NOTE: If RSA SecurID has not been configured, the RSA SecurID settings page only shows the Configure control.

Steps
1. Select the Settings icon, and then select Authentication in the Security section.
2. If not already selected, select RSA SecurID.
3. Do any of the following:
● To make changes to the RSA SecurID server information, select the pencil icon on the far right of the screen across from
RSA SecurID Server. The Edit RSA SecurID Server Settings slide out panel should appear.
○ Enable or disable RSA authentication.
NOTE: If the Enablement state is changed (either from Enabled to Disabled, or from Disabled to Enabled),
you are logged out of the current PowerStore Manager session when the change is applied.
○ Edit the RSA SecurID server information.
● To import an RSA SecurID CA certificate from the RSA SecurID server to replace the existing CA certificate that is being
used by PowerStore, select the pencil icon on the far right of the screen across from Certificate. You can select to
either import the certificate file or paste the certificate text (in PEM format) into the Import RSA SecurID Certificate
slide out panel.
● To view the certificate chain of the existing RSA SecurID CA certificate, click View Certificate Chain.
● View the list of user accounts that are configured to bypass RSA SecurID authentication.

Delete the RSA SecurID configuration

Prerequisites
RSA SecurID must be disabled before you can delete the RSA SecurID configuration.
NOTE: If RSA SecurID has not been configured, the RSA SecurID settings page only offers Configure to launch the
Configure Authentication wizard.

About this task

The delete operation deletes both the RSA SecurID configuration and the associated CA certificate from PowerStore.

18 PowerStore Manager
Steps
1. Select the Settings icon, and then select Authentication in the Security section.
2. If not already selected, select RSA SecurID.
3. Click Delete.
Delete RSA SecurID Configuration confirmation dialog box appears.
4. Click Delete.

Results
Both the RSA SecurID configuration and the CA certificate associated with the RSA Authentication Manager are deleted from
PowerStore.

Replace the existing RSA SecurID configuration

About this task
To replace an existing RSA SecurID configuration, which includes its associated RSA SecurID CA certificate, from PowerStore,
do the following:

Steps
1. Delete the existing RSA SecurID configuration. See Delete the RSA SecurID configuration.
RSA SecurID is not configured. The RSA SecurID settings page only shows the Configure control.
2. Set up the new RSA SecurID configuration. See Set up the RSA SecurID configuration on PowerStore
NOTE: When the previous configuration is deleted, the bypassed users remain as bypassed. Bypass Users shows the
current list of bypassed users as a comma-separated list if there is more than one.

Roles and privileges

Role-based access controls allow for users to have different privileges. This access provides a means to separate administration
roles to better align with skill sets and responsibilities.
The following table lists the roles and privileges that are related to block that the system supports:

NOTE: A in a box denotes a supported privilege for that role while a blank box denotes the privilege is not supported
for that role.

Table 6. Roles and privileges related to block

Task Operator VM Security Storage Administrator Storage
Administrator Administrator Administrator Operator
Change your system local
password.
View system settings,
status, and performance
information.
Modify system settings.

Create, modify, delete

protection policies.
Enable or disable SSH.

Create, modify, delete

volumes, and attach,
detach, snapshot, restore,
refresh, clone.

PowerStore Manager 19
Table 6. Roles and privileges related to block (continued)
Task Operator VM Security Storage Administrator Storage
Administrator Administrator Administrator Operator
Create, modify, delete
volume groups, add
and remove members,
snapshot, restore, refresh,
clone.
Create, modify, delete
vVols.
Create, modify, delete
storage containers, and
mount, unmount, and
create directory.
Create, modify, delete
vCenter.
View a list of local
accounts.
Add, delete, or modify a
local account.
View system storage
information through a
vCenter server that is
connected to the VASA
provider.
View and modify metro
node application IP address.
Use credentials to register
VASA Provider in vSphere.

Roles and privileges related to file

The following table lists the roles and privileges that are related to file that the system supports:

NOTE: A in a box denotes a supported privilege for that role while a blank box denotes the privilege is not supported
for that role.

Table 7. Roles and privileges related to file

Task Operator VM Security Storage Administrator Storage
Administrator Administrator Administrator Operator
View the following:
● File system alerts
● NAS server list
● File system list
● File user quota list
● File interface route list
● File interface list
● SMB share list
● NFS export list
View the following:

20 PowerStore Manager
Table 7. Roles and privileges related to file (continued)
Task Operator VM Security Storage Administrator Storage
Administrator Administrator Administrator Operator
● List of file DNS servers
or a specified DNS
server
● List of file FTP servers
or a specified FTP
server
● List of file interfaces or
specified file interface
● List of file interface
routes or a specified
interface route
● List of file Kerberos
servers or a specified
Kerberos server
● List of file LDAP servers
or a specified LDAP
server
● List of file NDMP
servers or a specified
NDMP server
● List of file NIS servers
or a specified NIS
server
● List of file systems or a
specified file system
● List of file tree quotas
or a specified file tree
quota
● List of file user quotas
or a specified user
quota
● List of file virus
checkers or a specified
file virus checker
● List of NAS servers or a
specified NAS server
● List of NFS exports or a
specified NFS export
● List of NFS servers or a
specified NFS server
● List of SMB servers or a
specified SMB server
● List of SMB shares or a
specified SMB share
Add, modify, delete, or
ping, a specified NAS
server, or upload password,
hosts, or groups to a
specified NAS server .
View the password of a
specified NAS server.
View the hosts of a
specified NAS server.
Add a file system, or modify
or delete a specified file

PowerStore Manager 21
Table 7. Roles and privileges related to file (continued)
Task Operator VM Security Storage Administrator Storage
Administrator Administrator Administrator Operator
system on an existing NAS
server.
Add a clone or snapshot
to a specified file system,
or refresh or restore a
specified file system, or
refresh the quota of a
specified file system.
Add a file tree quota, or
modify, delete, or refresh a
specified file tree quota.
Add a file user quota, or
modify, delete, or refresh a
specified file user quota .
Add a file virus checker,
or modify or delete a
specified file virus checker,
or upload a specified file
virus checker configuration.
Download a specified file
virus checker configuration.
Add an SMB or NFS server,
or modify, delete, join, or
unjoin a specified SMB or
NFS server.
Add an SMB share, or
modify or delete a specified
SMB share.
Add an NFS export, or
modify or delete a specified
NFS export.
Add a file interface, or
modify or delete a specified
file interface.
Add a file interface route,
or modify or delete a
specified file interface
route.
Add a file DNS, file FTP,
file Kerberos, file LDAP, file
NDMP, or file NIS server,
or modify or delete a
specified file DNS, file FTP,
file Kerberos, file LDAP, file
NDMP, or file NIS server.
Upload a file Kerberos
keytab.
Download a file Kerberos
keytab.

22 PowerStore Manager
Table 7. Roles and privileges related to file (continued)
Task Operator VM Security Storage Administrator Storage
Administrator Administrator Administrator Operator
Upload a file LDAP
configuration or LDAP
certificate.
Download of a file LDAP
certificate.
Use credentials to register
VASA Provider in vSphere.

User account management based on role privileges

A user with either an Administrator or Security Administrator role can perform the following actions:
● Create a user account.
● Change the role of another user account.
NOTE: The built-in Administrator account cannot be edited.
● Delete any user account, except the built-in Administrator account.
NOTE: Logged-in users cannot delete their own user account.
● Lock or unlock another user account.
NOTE: The built-in Administrator account cannot be locked and logged-in users with either an Administrator or Security
Administrator role cannot lock their own account.
● Reset the password for another user account.
Except for users with either the Security Administrator or Administrator role, logged-in users can only change their own
password. Users must provide their old password to change their password. Logged-in users cannot reset their own password,
change their own role, or lock or unlock their own accounts. When a user with the Administrator or Security Administrator
role changes the lock status, password, or role of a user or deletes a user, all sessions that are associated with that user are
invalidated.

NOTE: If a logged-in user updates their own password, the user session remains active.

Configuring LDAP authentication

Lightweight Directory Access Protocol (LDAP) is an application protocol for querying and modifying directory services
running on TCP/IP networks. LDAP helps centralize the management of network authentication and authorization operations.
Integrating PowerStore Manager users into an existing LDAP environment provides a way to control management access based
on established user and group accounts within the LDAP directory.
PowerStore supports the following LDAP server types:
● Active Directory—a Microsoft directory service. It runs on Windows Server and allows administrators to manage permissions
and access to network resources.
● OpenLDAP—a free, open-source implementation of LDAP.
Networked entities that exchange data use certificates to authenticate each other. For secure communications to occur
between two networked entities, one entity must trust (accept) the certificate from the other. PowerStore Manager uses the
SSL/TLS and the X.509 certificate standard to secure client (storage system) and server (LDAP) communications. PowerStore
requires the certificate chain file to be uploaded, to properly verify the server certificate received from the LDAP server when
the TLS session is established.
After you configure the LDAP settings for PowerStore, you can perform user management functions. For example, you can
assign access permissions to PowerStore Manager based on existing users and groups, within the context of an established
LDAP directory structure.
Follow this sequence of steps to configure LDAP on PowerStore:
1. Configure the LDAP server.
2. Verify the LDAP server connection.

PowerStore Manager 23
3. (Optional) Configure LDAPS for the LDAP server.
4. (Optional) Verify the LDAP server connection using the LDAPS protocol.
5. Configure LDAP Users and Groups.

Configure an LDAP server

About this task
LDAP server configuration consists of specifying the configuration information that is needed to connect to the LDAP server.
NOTE: LDAP services support the use of FQDN to identify and manage LDAP servers. The use of FQDN depends on the
configuration of the DNS service. To configure a basic DNS configuration to use LDAP FQDN addresses, ensure that the
DNS server is configured with the following information:
1. Networking setup for the PowerStore cluster to reach the IP address of the DNS server.
2. Permissions setup for the PowerStore cluster to query the DNS server, and that the queries are accepted and receive
replies.
3. The forward lookup zone of the DNS server is configured to resolve each LDAP FQDN address to their respective IP
address.
Do the following:
1. In PowerStore Manager, select Settings.
2. Under Networking, select Infrastructure Services.
3. Under DNS Server on the Infrastructure Services page, ensure that the latest configured IP address of the DNS
server is typed in the first IP address text box which is labeled (Required). In a multiple DNS server configuration,
either guarantee all DNS servers can resolve LDAP FQDN addresses or apply a temporary setting of an LDAP-only DNS
server while configuring LDAP.
NOTE: PowerStore with a multiple DNS server configuration performs a first successful lookup return. This means
that if the first DNS server is unsuccessful in returning an address lookup answer, the next DNS server is queried,
continuing to each DNS server in a round-robin style, until all the DNS servers have been queried.
To configure LDAP, do the following:

Steps
1. In PowerStore Manager, select Settings.
The Properties page appears with Settings displayed in the left panel.
2. In the left panel under Security, click Authentication.
The Authentication page appears with LDAP selected.
3. The options that appear under LDAP depend on whether LDAP has been configured. Do one of the following:
● To configure LDAP for the first time, click Configure LDAP. Go to the next step.
● To edit an existing LDAP configuration, click Edit LDAP Configuration. Go to the next step.
● To delete an LDAP configuration, click Delete LDAP Configuration.
When either Configure LDAP or Edit LDAP Configuration are selected, the Edit LDAP Configuration slide-out panel
appears. When Delete LDAP Configuration is selected, a confirmation dialog box appears that describes the effect of the
delete operation. If confirmed, all data, including certificates and LDAP user/role settings, are deleted.
4. Under LDAP Settings Server Type, select the type of the LDAP authentication server.
5. Under Servers, do one of the following:
● To manually add a server address, click Configure FQDN/IP Addresses Manually, enter the IP address or FQDN and
click Add.
NOTE: For PowerStore operating system versions earlier than version 3.0, only IP addresses are accepted, FQDN is
not supported. Operating system versions 3.0 or later, support both IP addresses and FQDN.
● To remove a server address, select the address in the list box and click Delete.
● To move an IP address or FQDN up or down in the list, select the address in the text box and click Up or Down,
respectively, as needed.
6. For Domain Name under Domain Settings, type the domain name of the LDAP authentication server.
The domain name must be entered when the LDAP server configuration is created. After that, it is disabled because it
cannot be changed without deleting and re-creating the LDAP server configuration.

24 PowerStore Manager
7. For Bind DN (Distinguished Name), type the distinguished name of the LDAP user with administrator privileges.
The distinguished name should be specified in one of the following formats:
● (For AD and OpenLDAP) LDAP notation format (for example,
cn=ldapbinduser,cn=Users,dc=mycompany,dc=com)
● (For AD only) <user>@<domain> format (for example, [email protected])
8. For Bind DN Password, type the password for the user specified in Bind DN.
9. For Timeout (secs), type the amount of time in seconds that will be allowed for the LDAP connection and query to occur.
10. For enabling Global Catalog for Active Directory, select Global Catalog.
The port automatically sets to 3268 and the default value for User ID Attribute under Advanced Settings changes from
sAMAccountName to UserPrincipalName.
11. The port for LDAP cannot be customized. The LDAP server uses one of the following default ports:
● 389 for LDAP
● 3268 for LDAP (global catalog)
For example, nsroot.net instead of nam.nsroot.net using LDAP allows customers to query the entire AD forest (port
3268) instead of the AD domain (TCP port 389). Also, AD role association is based on group scopes for Domain Local Groups
and Universal Groups. This association allows end-users to search the AD using an appropriate scope as needed and to avoid
unnecessary group searches.
NOTE: It is strongly recommended that LDAP be configured and verified before configuring Secure LDAP (LDAPS).
These actions will minimize any troubleshooting that may be necessary when enabling LDAPS.

12. Click Advanced Settings to list all the fields under User Search Settings and Group Search Settings. Verify the default
values and, if necessary, make changes if required.
For example, if the LDAP server has a different Search Path than the default cn=Users,dc= for either User Search
Settings or Group Search Settings, or both, click Advanced Settings and update the search paths or other fields as
necessary, then click Apply to save the advanced configuration changes.
NOTE: The default values that appear under Advanced Settings are based on the type of server as shown in the
following list:
● Active Directory server
○ User Search Settings:
￭ ID Attribute: sAMAccountName
￭ Object Class: user
￭ Search Path: cn=Users,dc=<domain>
○ Group Search Settings:
￭ Member Attribute: member
￭ ID Attribute: cn
￭ Object Class: group
￭ Search Path: cn=Users,dc=<domain>
￭ Search Level:
● Active Directory - Global Catalog server
○ User Search Settings:
￭ ID Attribute: UserPrincipalName
￭ Object Class: user
￭ Search Path: (grayed out)
○ Group Search Settings:
￭ Member Attribute: member
￭ ID Attribute: cn
￭ Object Class: group
￭ Search Path: (grayed out)
￭ Search Level:
● OpenLDAP server
○ User Search Settings:

PowerStore Manager 25
 ￭ ID Attribute: uid
￭ Object Class: inetOrgPerson
￭ Search Path:
○ Group Search Settings:
￭ Member Attribute: member
￭ ID Attribute: cn
￭ Object Class: groupOfNames
￭ Search Path:
￭ Search Level:

13. Update the search paths or other fields as necessary, then click Apply to save the advanced configuration changes.
For example, if you are configuring forest-level authentication, specify userPrincipalName in the ID Attribute field. If
the LDAP server has a different search path than the default (cn=Users,dc= ) for either users, groups, or both, update the
search paths or other properties as necessary.
14. After all the LDAP configuration information is specified, click Apply to save the configuration.

Next steps
After the LDAP server configuration is saved and to avoid the possibility of data being unavailable, you must verify the
configuration to confirm that the connections to the LDAP server will be successful.

Verify LDAP configuration

About this task

NOTE: To avoid the possibility of data being unavailable, you must verify the LDAP connection after every LDAP
configuration change.
To verify connection to the LDAP server will be successful, do the following:

Steps
1. On the Authentication page with LDAP selected, click Verify Connection.
If the configuration is valid, a connection will be established with the LDAP server and a green check mark along with the
text Connection Verified will appear.
2. If the verification fails, the following steps are recommended to troubleshoot the failure:
a. Verify the LDAP configuration information, in particular the Distinguished Name (user name), Password, and the
Server Address (IP address or FQDN).
b. Verify the LDAP server is online.
c. Verify there are no network issues; for example, firewall rules that would block access to the LDAP port, network router
configuration that prevents the connection, and such.

Configure Secure LDAP

About this task

Configuring Secure LDAP (LDAPS) requires the following:
NOTE: It is strongly recommended that LDAP be configured and verified before configuring Secure LDAP (LDAPS). These
actions will minimize any troubleshooting that may be necessary when enabling LDAPS
● Configure LDAPS protocol and the port
● Configure the certificate chain
When LDAPS is configured, PowerStore connects to the LDAP server using TLS. PowerStore requires the certificate chain file
to be uploaded, to properly verify the server certificate received from the LDAP server when the TLS session is established.
PowerStore supports DNS for LDAP. The LDAP server certificate must have either IP addresses or FQDNs, as specified in
the LDAP configuration, in the Subject or Subject Alternative Name field in the certificate. This is required to verify that the
certificate is from the desired LDAP server.

26 PowerStore Manager
The format of the certificate file to be uploaded is as follows:
● The certificate file must end in one of the following file extensions:
○ .pem
○ .crt
○ .cer
○ .ca-bundle
Example: LdapServerChain.crt
● All certificates in the certificate file to be uploaded must be in PEM format. PEM formatted certificates contain ASCII text
that begins with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----.
NOTE: For more information see Format of a certificate or certificate chain before importing it.
● If the LDAP server certificate is self-signed, only the server certificate is required.
● If the LDAP server certificate is signed by a Certificate Authority, then the certificate chain, up to the root certificate
Authority, must be in the certificate file to be uploaded in the following order:
1. Intermediate Certificate Authority certificate (if any).
2. ...
3. Root Certificate Authority certificate.
4. If there are multiple certificates in the file to be uploaded, there must be a new line between each certificate.
To configure LDAPS, do the following:

Steps
1. Click Edit LDAP Configuration.
The Edit LDAP Configuration slide out panel appears.
2. Under Domain Settings, select the LDAP Secure (Use SSL) checkbox.
The port for LDAPS cannot be customized. The LDAP server uses one of the following default ports:
● 636 for LDAPS
● 3269 for LDAPS (global catalog)
For example, nsroot.net instead of nam.nsroot.net using LDAPS allows customers to query the entire AD forest (port
3269) instead of just the AD domain (TCP port 636). Also, AD role association is based on group scopes for Domain Local
Groups and Universal Groups. This allows end-users to search the AD using an appropriate scope as needed and to avoid
unnecessary group searches.) Also, Upload for LDAP Certificate appears when the LDAP Secure (Use SSL) checkbox is
selected.
3. Click Upload.
The Upload File dialog box appears.
4. Click Choose File.
5. Browse to the desired certificate file, then select the file and click Open.
6. After the file upload completes, click Apply to save the configuration changes.

Next steps
You must verify the configuration after configuring LDAPS and uploading the server certificate file.

Verify LDAPS configuration

About this task

NOTE: To avoid the possibility of data being unavailable, you must verify the LDAPS connection after every LDAPS
configuration change.
To verify the LDAPS configuration, do the following:

Steps
1. On the Authentication page with LDAP selected, click Verify Connection.
If the configuration is valid, a connection will be established with the LDAP server and a green check mark along with the
text Connection Verified will appear.
2. If the verification fails, the following steps are recommended to troubleshoot the failure:

PowerStore Manager 27
 a. Verify the LDAP configuration information, in particular the port number.
b. Verify the LDAP server is online and configured for LDAPS.
c. Verify the certificates in the uploaded certificate file are valid, for example, not expired and in the correct order.
d. Verify the configured FQDN or IP address is in the Subject or Subject Alternative Name field in the LDAP server
certificate.
e. Verify there are no network issues; for example, firewall rules that would block access to the LDAPS port, and such.

Next steps
After the LDAP server is configured, one or more LDAP users or groups must be added to PowerStore to map the users (or
groups) to roles. Otherwise, LDAP authentication will succeed on login, but the login will fail because no role could be assigned
to the user.

Configure LDAP account

About this task
The procedure for creating an LDAP user or group account on PowerStore is similar. However, the LDAP group must also be
created on the LDAP server, and LDAP users added as members of that group. The advantage of creating an LDAP group
account is that all the users which are members of the added group get access to PowerStore with the privileges and role
mapped to that group.
To create an LDAP user or group account, do the following:

NOTE: LDAP server must be configured before an LDAP user or group account can be created.

Steps
1. In PowerStore Manager, click Settings in the top menu bar to display the Settings page.
2. In the left panel under Security, click Users.
The Powerstore Users page appears.
3. Click LDAP.
The LDAP account information appears.
4. Click Add.
The Add Account slide out panel appears.
5. For Type, select the type of LDAP account, either User or Group.
6. For Account Name, type the user name that is listed in the LDAP server.
NOTE: The account name must be the value of the ID Attribute defined in Advanced Settings under Domain
Settings on the Directory Services slide out panel. For example:
● When Global Catalog (forest-level authentication) is selected while configuring the PowerStore LDAP server, the
default value for User ID Attribute under Advanced Settings is UserPrincipalName. So the Account Name
must be a UserPrincipalName which is unique, and the format is [email protected]
● When Global Catalog is not selected, the default value for the User ID Attribute under Advanced Settings is
sAMAccountName. The Account Name must be an sAMAccountName.
● When adding a group, the Account Name must be the value of the Group ID Attribute (example: cn)
Also, the account name cannot include colon (:), backslash (\), slash (/) or at (@) characters.

7. For Account Role, select the role to assign to the account from the drop down list.
8. After verifying that the LDAP user or group name and the role are correct, click Apply to complete the transaction.
The added LDAP user or group account appears in the list of accounts on the Powerstore Users page.
9. If the adding LDAP account operation fails, do the following to troubleshoot the failure:
a. Verify the fields in User Search Settings under Advanced Setting are correct.
b. Verify the fields in Group Search Settings under Advanced Setting are correct.
c. Verify that the group search level is set properly.

28 PowerStore Manager
Login message
The login message provides a way for a user with Administrator or Security Administrator privilege to communicate important
information to users. For example, the login message can be customized to show a legal disclaimer about using the PowerStore
system. When you enable this feature, the login message appears in the PowerStore Manager login page.
Enabling or disabling the Login Message feature and changing the message text are cluster-wide operations. The same login
message is displayed for the whole cluster.

NOTE: The login message has a maximum limit of 2000 characters.

NOTE: When STIG is enabled in the PowerStore cluster, the behavior of the Login Message feature changes. A fixed
Department of Defense (DoD) banner opens when the user logs in. The user must click Accept to continue to the default
PowerStore Manager dashboard. Also, the DoD banner is displayed in the service environment, whether it is accessed
through SSH or the console. The DoD banner cannot be replaced by using the Login Message feature (by either selecting
Login Message in PowerStore Manager or by using the login_banner REST API).

Manage login message settings

About this task
Only a user with Administrator or Security Administrator privileges can manage the settings for the Login Message feature.
To manage the login message settings using PowerStore Manager, do the following:
NOTE: You can also manage the login message settings through the CLI or the REST API. For detailed information, see the
related PowerStore REST API Reference Guide or PowerStore CLI User Guide.

Steps
1. Click Settings and under Security, select Login Message.
The Login Message page appears.
2. Do any of the following:
● Enable or disable the feature.
● Change the Message text.
NOTE: The feature must be enabled to change the Message text. When STIG is enabled, a fixed Department of
Defense (DoD) banner is shown. The DoD banner cannot be edited or replaced.
3. Click Apply to save the changes.
NOTE: When any changes are made in the Login Message page, you must click Apply before you can navigate from
the page. Otherwise, a prompt appears asking whether to cancel the navigation move or to discard the changes that you
have made.

Reset admin and service account passwords

The appliance ships with a default admin user account that lets you perform the initial configuration. It also ships with a
default service user account that lets you perform specialized service functions. It is recommended that you initially configure
PowerStore using the PowerStore Manager UI rather than another method such as the REST API or the CLI. Using the
PowerStore Manager UI ensures that all the default passwords are changed. If you forget the new passwords, you can reset the
passwords back to their default values.

Reset admin and service account passwords to their default values using the
NMI button in a PowerStore appliance
About this task
Use this procedure to reset both the service and admin passwords to their respective default value.

PowerStore Manager 29
 NOTE: This procedure is applicable to PowerStore operating system version 2.1 or later and is the only way to reset the
password in the following cases:
● The service password is forgotten or unknown.
● You are not already logged in to PowerStore Manager.
● Password reset using a USB drive is not available.

Steps
1. Locate the nonmaskable interrupt (NMI) button for the node at the rear of the appliance.
The button is on the embedded module of the node, inside a small hole identified by two triangles vertically pointing at each
other.

2. Using a thin nonmetallic object, press and hold the NMI button for only one or two seconds, then release it.
CAUTION: Do not press too hard, you can damage the embedded module board or the NMI button.

NOTE: Be careful. Pressing the NMI button for more than ten seconds resets (reboots) the node. Also, do not attempt
another NMI password reset on the same node within two minutes.

You should feel a click. If you do not, you may not be making contact with the button. Once the appliance has detected the
NMI button press, the appliance starts the password reset procedure.
3. Connect to the management IP address of the PowerStore appliance using a browser and log in as admin with the default
initial password Password123#.
You should receive a prompt to reset both admin and service passwords.
4. Change the admin password from the default to a user specified password. Clear the checkbox if you want to set the service
account password to be different from the admin password.
NOTE: If you are not prompted to reset the password upon login, repeat steps 1-4 on the other node. Take this action
only if you are not prompted to reset the password on the first attempt. If you are still not prompted to reset the
password on each login attempt after trying once on each node, contact your service provider.

Reset admin and service account passwords to their default values using a
USB drive in a PowerStore appliance
About this task
NOTE: This procedure is applicable to PowerStore operating system version 2.0 or earlier. For PowerStore appliances with
operating system versions from 2.1 to 3.5, the NMI button can be used instead. See Reset admin and service account
passwords to their default values using the NMI button in a PowerStore appliance. For a PowerStore appliance with
operating system version 3.6 or later, the USB drive is disabled and the NMI button must be used instead.
For a PowerStore appliance, reset the admin or service user passwords using a USB drive. Supported file systems include FAT32
and ISO 9660.
NOTE: To reset the password if both nodes on the appliance are in Service Mode, use the following steps with one
difference. Apply the USB reset process to each node. This action ensures that when the system is returned to Normal
Mode and upon PowerStore Manager login, you are prompted to provide a new password for both the admin and service
users.

Steps
1. If the USB drive is formatted, go to the next step; otherwise, use a command prompt such as: format <d:> /FS:FAT32
to format the drive.
Where d: is the drive letter for the USB drive that you have inserted into your laptop or personal computer.

2. Set the label with the command:

label d:
RSTPWD

30 PowerStore Manager
 NOTE: The appliance will not mount the USB drive without the RSTPWD label. After labeling the USB drive, insert an
empty file for the account passwords that you would like to reset. You can reset the admin or service account password,
or both.

3. To create an empty file on the drive, use one or both of the following commands as needed:

copy NUL d:\admin

copy NUL d:\service

4. Insert the USB drive into the USB port of either node of the appliance, wait 10 seconds, and then remove it.
The password for each account you reset is now the default value.
5. Connect to the cluster through a browser using the cluster IP address and log in as admin with the default initial password,
which is Password123#.
A prompt to reset the admin or service passwords, or both should appear. If you prefer to reset the service password using
secure shell (SSH), the initial default password for the service account is service.
6. Change the admin password from the default to a user specified password.
7. To set the service account password to be different from the admin password, clear the related check box.

Results
If you are still not prompted to reset the password on a login attempt after running this procedure, contact your service
provider.

Certificates
Data in the certificate store of PowerStore is persistent. The certificate store stores the following types of certificates:
● Certificate Authority (CA) certificates
● Client certificates
● Server certificates

Viewing certificates
About this task
The following information appears in PowerStore Manager for each certificate that is stored on the appliance:
● Service
● Type
● Scope
● Issued by
● Valid
● Valid Till
● Issued To
NOTE: Use the REST API or CLI to view additional certificate information.

To view the certificate information, do the following:

Steps
1. Launch the PowerStore Manager.
2. Click Settings and under Security click Certificates.
Information about the certificates stored on the appliance appears.
3. To view the chain of certificates that comprise a certificate and associated information for a service, click the specific
service.
View Certificate Chain appears and lists information about the chain of certificates that comprise the certificate.

PowerStore Manager 31
Signed cluster certificate
The certificate and credential infrastructure of PowerStore provides a mechanism to manage local and third-party Certificate
Authority (CA) signed certificates. Normally, Web traffic is secured by the server certificate signed by the PowerStore CA.
However, there are cases when a client requires using a certificate signed by their own CA (third-party CA). A third-party
CA signed server certificate is owned by the PowerStore client and is used for all trust operations. For example, the
U.S.Department of Defense client has its own CA that is used to sign the server certificates. When PowerStore presents
the server certificate to the client (for example, a browser), which is signed by the client's CA, a trust is established during TLS
session establishment. In this case, the server certificate that is used for the external communication path to establish the TLS
session is signed by the third-party CA and must be imported into the PowerStore credential store.
Two types of certificates are imported as part of the server certificate chain import:
● CA certificate
● Server certificate
To increase security, some organizations use CA certificate chaining. Certificate chaining links two or more CA certificates
together. The primary CA certificate is the root certificate at the end of the CA certificate chain. The system requires the CA
certificate (the immediate signing authority is mandatory, but the CA certificate chain is optional) to verify the authenticity of
the certificate that is received. Ask the directory server administrator if certificate chaining is used. If so, you must concatenate
all the relevant certificates into a single file and upload that version. The certificate must be in PEM/Base64 encoded format.
Either the server certificate with the immediate signing authority or the whole CA certificate chain must be imported as part of
the server certificate import. During a third-party CA signed server certificate import, PowerStore replaces the existing server
certificate with the new certificate, regardless of whether the existing server certificate is PowerStore CA signed or signed by
another third-party CA.

Format of a certificate or certificate chain before importing it

When importing a certificate or certificate chain, the format of the information is important. The plain-text headers and footers
must be terminated by LF (or newline) characters. The certificate strings must not contain any line terminations except at the
end (before the footer). In a chain, each certificate in the chain should be formatted this way. Any intermediate certificate or
certificates and (optionally) the root certificate should follow this format. However, the final certificate in an uploaded chain
should not be followed by a LF character.
The order of the certificates in a chain is also important. For example, the following command is an example of how to construct
a certificate chain for import:

cat leaf.pem intermediate.pem root.pem > combined.pem

The following abbreviated example shows a certificate chain that has been formatted for import:
NOTE: The newline characters (\n) in the example show where the plain-text headers and footers must be terminated.
Ellipsis (...) in the example are used only to represent long strings of text in the actual certificates.

-----BEGIN CERTIFICATE-----\nMIIDGjCCAg ... z/iv/f+MEq\n-----END CERTIFICATE-----\n-----

BEGIN CERTIFICATE-----\nMIIC7jCCAd ... okHonrDg==\n-----END CERTIFICATE-----\n-----BEGIN
CERTIFICATE-----\nMIIC5jCCAc ... T/bCWjjrk=\n-----END CERTIFICATE-----

Import a signed cluster certificate

Prerequisites
Before importing the certificate, ensure the following:
● A Certificate Signing Request (CSR) file was generated, downloaded and sent to the third party Certificate Authority (CA)
server for signing.
● The certificate authority (CA) has signed the certificate so that it can be imported as a Mutual Authentication Certificate.
● You know the location of the certificate file or have the certificate text available to copy and paste for import.
Also, you should consider the following items before initiating the certificate import process:
● To avoid interruptions to your PowerStore Manager session, only import the new CA certificate into your browser if it has
not already been imported or it is being renewed.
● Adding a remote system is not allowed while the certificate import is in process.

32 PowerStore Manager
● Avoid initiating new replication operations during the certificate import process.
● There is a potential for temporary TLS connection loss during the certificate import process due to server certificate
switching.
● Reloading your browser may be necessary when the certificate import process completes.

About this task

NOTE: The following procedure applies only to PowerStore operating system versions 3.0 or later.

This procedure imports a CA certificate. It also pushes the certificate to associated PowerStore appliances that have active
replications.
To import a signed cluster certificate using the PowerStore Manager, do the following:

Steps
1. Select Settings and under Security select Signed Cluster Certificate.
The Signed Cluster Certificate page appears.
2. Select Import.
NOTE: If a certificate import job is already in progress or a CSR has not been generated for the certificate, Import is
greyed and cannot be selected.

The Import Third Party Signed Server Certificate dialog box opens. It contains the list of the items that you should
consider before initiating the certificate import process.
3. Do one of the following:
● Select Select Certificate File, then locate and select the file to import.
● Select Paste Certificate Text, then copy and paste the certificate text in the text box.
NOTE: Remove a newline ASCII character within the lines of each certificate in the certificate chain and format the
certificate lines into a single line for each certificate in the chain.

4. Select Import.
The following should occur:
● An asynchronous job starts and a pop-up appears that shows the progress of the certificate import.
NOTE: If you navigate away from the page but remain in the same browser session and then return to the page, the
import operation progress should appear under Recent activities.
● Import is greyed and cannot be selected until the import job completes.
● When the import operation completes, a notification appears on the page along with a scroll pane that contains the
certificate chain information, and the import operation complete status is shown under Recent activities.

Generate a Certificate Signing Request

Prerequisites

NOTE: This procedure is applicable to PowerStore operating system version 3.0 or later.

Before you generate a Certificate Signing Request (CSR), ensure that you have obtained the following information for the
request:
● Common Name
● (optional) Additional cluster IP addresses
NOTE: Cluster IP and ICM IP addresses are automatically entered and are read-only.
● DNS Name
● Organization
● Organization Unit
● Locality
● State
● Country
● Key Length

PowerStore Manager 33
About this task
Generating a CSR is applicable to a Mutual Authentication Certificate, which is used in two-way authentication. To generate a
CSR to import a third-party Certificate Authority (CA) signed server certificate, do the following:

NOTE: This procedure is applicable to PowerStore operating system version 3.0 or later.

Steps
1. Select Settings and under Security select Signed Cluster Certificate.
2. Select Generate CSR.
The Generate CSR slide out appears.
3. Type in the information that is used to generate the CSR.
4. Click Generate.
The Generate CSR slide out changes to show the next steps that must be taken along with the certificate text.
5. Click Copy to clipboard to copy the certificate text to your clipboard.
6. Click Close.
7. Have the certificate signed by the certificate authority (CA) so that it can be imported as a Mutual Authentication
Certificate.
NOTE: Alert the personnel at the certificate authority that they should honor the Requested Extensions so that the
Subject Alternative Name field is populated with the DNS name, the Cluster IP, and the ICM Cluster IP in the leaf
certificates. This action will ensure that PowerStore features such as non-disruptive upgrade (NDU), Pre-Upgrade
Health Check, and Data Collection function correctly.

Import a third party Certificate Authority signed server certificate

Prerequisites
The PowerStore CLI commands used in importing a third party CA signed server certificate must be run in non-session mode.
The following is a format example for CLI commands in non-session mode:

pstcli -d <mgmt_ip> -u <user> -p <password> /<command1> …

pstcli -d <mgmt_ip> -u <user> -p <password> /<command2> …

The following is a format example for CLI commands in session mode:

pstcli -d <mgmt_ip> -u <user> -p <password> -session

cli> <command1>
cli> <command2>
cli>

If you are in session mode, type exit at the cli> prompt to exit session mode.

About this task

NOTE: The following procedure applies only to PowerStore operating system version 2.1.x. For PowerStore operating
system versions 3.0 or later, see Generate a Certificate Signing Request and Import a signed cluster certificate.
To import a third party Certificate Authority (CA) signed server certificate, do the following:

Steps
1. Generate a Certificate Signing Request (CSR) and record the ID for the certificate which appears in the CSR response.
The ID for the certificate is needed to import the third party CA signed server certificate.
NOTE: Use either the PowerStore REST API or CLI to generate the CSR. ip_addresses in the request part of the
following REST API and CLI CSR examples refers to the cluster IP address. The following is an example of using the
REST API and 5beb91ac-8bd9-430f-bf7a-dd912396d699 is the ID for the certificate:

Request -
https://10.0.0.1/api/rest/x509_certificate/csr
{

34 PowerStore Manager
 "type": "Server",
"service": "Management_HTTP",
"scope" : "External",
"common_name" : "www.mycompany.com",
"dns_name":["pwrstr1.corp.com],
"ip_addresses":["10.0.0.1"],
"organizational_unit":"Security",
"organization":"mycompany",
"locality":"mycity",
"state":"mystate",
"country":"US",
"key_length":2048"
}

Response -
{
"id": "5beb91ac-8bd9-430f-bf7a-dd912396d699",
"type": "Server",
"service": "Management_HTTP",
"scope": "External",
"is_current": false,
"is_valid": false,
"member": [],
"certificate_request": "-----BEGIN CERTIFICATE REQUEST-----
\nMIICzjCCAbYCAQAwZzFlMAkGA1UEBhMCVVMwCgYDVQQKEwNFTUMwDwYDVQQLEwhT\r\nZWN1cml0eTAQB
gNVBAcTCUhvcGtpbnRvbjATBgNVBAMTDHd3dy5kZWxsLmNvbTAU\r\nBgNVBAgTDU1hc3NhY2h1c2V0dHMw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK\r\nAoIBAQDO735I6nZrhqQrfsMLd0ckwlp7i9DAEMczeXB
jMLZ74wJn8F3JaAuORY/
A\r\nHBkOUGgVnGlYnVcBNNo4YxYeZjiUJhR9Kav7IPNeJPPw3hTECpRbHljHpwppIf5p\r\ntAUnpNXF3n
DLXma7lWRB16TCnvbvRTDqAwfB2CeZy+UrvgSdxqk5RQfV1lSQXNn/\r\nA40uv5AhDQolHSQv/
ktSvxGdgIAXgUCw7DDMgZduHcJPDsD5TO5Lbop7cjg41YqI\r\nCbUevrbnit4DwWMipRbN1fcH0b7e+twN
yeHE550M0dpK+UMOgKX4wnTRIylDAx3m\r\nYiHR+wGrpbqbO3IOUdWN7WW0ECxdAgMBAAGgIjAgBgkqhki
G9w0BCQ4xEzARMA8G\r\nA1UdEQQIMAaHBAr0HHYwDQYJKoZIhvcNAQELBQADggEBACjkV0PXgUXnqD1c4k
mE\r\nrl/olcqWp7OgaM79jt+IJBoF1/h3niNBtjY4QDDvZs8gIoITopAMokhH/
J8fEhw0\r\nK2kxqp36sefSswrOe5331lcbiaV4iEhXpHwHb40UV9SWkEcxzNOXKrq+A6Rfklow\r\n+k6A
aLfRKhX/6dyQPV50dZYqGTfogv5SdyPh+MfY4J06uRDmcDd4wQoQIpC2g/
nF\r\nlalTAFIjff7gcUcaXekjXIplP2r3XbJ+KxPVXSIbY4sbIEbKnowDXJ0c/
87DB1yX\r\nEXe3TQYA6mlRP+kqYVa11y9DWx9ljTpde9CariiUUqo08UoEWWo9k5p9fF0/
gIxy\r\nXZY=\n-----END CERTIFICATE REQUEST-----\n"
}

The following is an example of using the CLI and 0e82aae7-6d56-4e0f-9178-eee1759bf4b3 is the ID for the
certificate:

$ pstcli -u admin -p Passphrase123 -d 10.0.0.1 x509_certificate csr -type "Server"

-service "Management_HTTP" -scope "External" -common_name "www.dell.com" -dns_name
"pwrstr1.corp.com" -ip_addresses "10.0.0.1" -organizational_unit "security"
-organization "mycompany" -locality "mycity" -state "mystate" -country "US"
-key_length 2048
Success
# | id |type|service|scope|is_current|is_valid|

certificate_request

--+------+----+-------+------+----------+--------+---------------------------------
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------------
------------------------------
1 | 0e82aae7-6d56-4e0f-9178-eee1759bf4b3 | Server | Management_HTTP | External |
no | no | -----BEGIN CERTIFICATE REQUEST-----
MIIC4jCCAcoCAQAwZzFlMAkGA1UEBhMCVVMwCgYDVQQKEwNFTUMwDwYDVQQLEwhz
ZWN1cml0eTAQBgNVBAcTCUhvcGtpbnRvbjATBgNVBAMTDHd3dy5kZWxsLmNvbTAU
BgNVBAgTDU1hc3NhY2h1c2V0dHMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDIO0Q23XbhjFVbZGyoYZoqe7A7F1otJNKN0LJcWc6E2Z3g358E+u2bFjkE
kQ2UKCABw5sDVgogiK7AiF9Hsk6fObyAacwHTp75QKUtX2YDExE7n92DS6k76pbf
ZVlZAIjsWPIvwvnFD4FYOW6c86P0Vg3PGB562bEpnYkjKSLIURdmPj08gSGv9Apk

PowerStore Manager 35
 SDw1+IXslsdWIr908JFBoAaqNlYiuW5nNXjK54VQDVX+Z+SZsy+ABiw6DobXbbgu
UzeUJb3bQKg1C9hW8En865tXGMCc0vYhW9oO/Z6uJa0QP8D/tIzqKveeaGnwjrlw
om/8FNtmckgOZ83nJ4e35m1EivSjAgMBAAGgNjA0BgkqhkiG9w0BCQ4xJzAlMCMG
A1UdEQQcMBqCAIcECvQcDocQ/Y42Q5YTAAACAUQrvqQSCTANBgkqhkiG9w0BAQsF
AAOCAQEAH9xJuSpCpa0iSBXIYBKcJgEw3TXGEeYzI7wOtAf8/hzotC/n7ZcUkUFd
TbfwCSupeeMctYYoEhHXKa+oOaFeIxPvt9vrtpvZyTTvgrNtViD642DTYmoZkrpW
OJuMPCcSv9p8GVqPPsM5U0bDntdlGsZXhWqagNG5Y17HeRfthDS+LEO6bDKQj+ER
sTgEL5qsAS2eAimkGwIKVAnr9drvplMcurK8ZzgroK0xNAuiKtsB/fk9hfcF9LBz
LYc/1bTosSASf/QFJmHg0Ek/bGjtkSHE9wlor+phQGzggg2ioTqtZUVUJaR/52Sz
PFrPDO07mk7z99VsJUNsxKK32rtjZQ== -----END CERTIFICATE REQUEST-----

For information about the associated REST API command, see the PowerStore REST API Reference Guide. For
information about the associated CLI command, see the PowerStore CLI User Guide.

2. Save the generated CSR in a file on a local computer.

NOTE: Make sure that you have generated the CSR and saved it in a file before generating the certificate to
be imported into PowerStore. Ensure that the contents of the CSR file do not contain any trailing or leading
whitespace characters. Also, remove the carriage return (/n) that may appear immediately after the text -----BEGIN
CERTIFICATE REQUEST----- and immediately before the text -----END CERTIFICATE REQUEST-----, if
they exist. The following is an example of the contents of a saved CSR file:

----BEGIN CERTIFICATE REQUEST----

MIIC4jCCAcoCAQAwZzFlMAkGA1UEBhMCVVMwCgYDVQQKEwNFTUMwDwYDVQQLEwhz
ZWN1cml0eTAQBgNVBAcTCUhvcGtpbnRvbjATBgNVBAMTDHd3dy5kZWxsLmNvbTAU
BgNVBAgTDU1hc3NhY2h1c2V0dHMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCpPuoRWLYAAbTMbO+Seveu/sLcnGtiwIEia6+/u0tueV+kI4VI+jSAvfhg
pj9abeiLy4C3Ox97I3XpGl2uUzvxpIFW57JsWBrW/qeUj2EeJOlf91b5Q7tgo5Ir
RxZ0K2kjdTVXnob+xSd2gA1RAiOsExW39Cu6vkKgBq0ubUGn6nPf5prMG+98bfqJ
oUeIat/qWuB23DM+AgDs2oG32sg0IaDthPdDWOR7suVAC36emsQnVUTNV9cJ6/c4
Q95inwMhXKwaHSy53ZlWpHYYhkwcysFqflV5OV1KXYk/TFeNyCy7edoTXTfiijTP
sbUNrhqdm4eKrueN+S/JIHGJ3dLDAgMBAAGgNjA0BgkqhkiG9w0BCQ4xJzAlMCMG
A1UdEQQcMBqCAIcECvEHeIcQ/Z/ubkaZAAACAUSFMUoWyTANBgkqhkiG9w0BAQsF
AAOCAQEAGwGG/7qxnFBVZVu0sbdbblNTgDtOmPWqeKcBs7TA5YAoOYaljMlpQsY7
gMUWhB/l4WP7S/fZiAfbyKisZMGz0SMyWEQs3c05nYnDTiUFfZf+aywniV0euTEb
sOHqdU/Vh3ZyS7IfnpYloOQzbu8qSOx8amMAWEbrNI0rTwhehaAxyUblXuFdEcmq
PEope+XrhVGgk99+GghHccmw4kAeSXMGy/ovGH90ig0lHbF6eJV4+is5yCU4cwQl
hfIodnVLOngWpPHK+8BGR0EkIDW+g83I5fxro32W5BGvqq6YfP+4YyB4F3uyQx+c
TxSY21cComKeL6BiNcgM4e5Tk393DA==
----END CERTIFICATE REQUEST----

3. Send the CSR file to the third party CA server for signing.
4. Decode the CSR contents.
NOTE: Use a CSR decoder website utility or OpenSSL command. The following is an example of the OpenSSL
command:

openssl req -in pst.csr -noout -text

5. From the decoded CSR output, record the cluster ICMP IP and cluster IP addresses that are listed for the Subject
Alternative Name.
The following decoded CSR output excerpt is an example that contains a cluster ICMP IP address and a cluster IP address
shown in bold:

Requested Extensions:
X509v3 Subject Alternative Name:
DNS:, IP Address:FDCE:515:383C:0:201:4473:7688:A8F9, IP Address:10.0.0.1

6. Do one of the following:

● For a centralized CA where the CA public certificate is installed on clients and browsers, present the CSR to the CA and
request a certificate that includes the following attributes in a Subject Alternative Name field:
NOTE: The IP.1 and IP.2 attributes are mandatory. The DNS.1 and DNS.2 attributes are optional.

○ IP.1 = Cluster IP address

○ IP.2 = ICM IPv6 address

36 PowerStore Manager
 ○ DNS.1 = PowerStore FQDN (for example, pst1.corp.com)
○ DNS.2 = second PowerStore FQDN (for example, pst1.storage.corp.com)
When you receive the CA signed server certificate, go to 12.
● If a central CA is not available, got to 4.
7. Create a SAN.cnf file.
NOTE: The SAN.cnf file needs to be incorporated into the certificate. The following is an example of creating a SAN.cnf
file:

$ cat san1.cnf
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
[ req_distinguished_name ]
countryName = US
stateOrProvinceName = Massachusetts
localityName = Hopkinton
organizationName = EMC
commonName = www.emc.com

[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.emc.com
DNS.2 = rip3-appliance-1.svt12.lab.emc.com
IP.1 = 10.241.7.120
IP.2 = FD9F:EE6E:4699:0:201:4485:314A:16C9

8. Delete the DNS information and replace the IP addresses listed for the SubjectAltName in the SAN.cnf file with the
cluster ICMP IP and cluster IP addresses that you recorded in 5 which were listed for the Subject Alternative Name in the
CSR.
In the previous example, the following DNS information would need to be deleted:

DNS.1 = www.emc.com
DNS.2 = rip3-appliance-1.svt12.lab.emc.com

and IP.1 and IP.2 would need to be replaced with

IP.1 = FDCE:515:383C:0:201:4473:7688:A8F9
IP.2 = 10.0.0.1

9. Use the CSR to generate the server certificate that is signed by the third party CA and pass the edited SAN.cnf file on the
command line while generating the certificate.
NOTE: Make sure to use the latest and correct CSR that was generated by PowerStore during the certificate creation
process.

10. Create a signed CA-certificate.

11. Once the entity certificate is created with the certificate chain (intermediate and root CAs), combine them into a single pem
file.
Use the following structure:

cat leaf.pem intermediate.pem root.pem > combined.pem

The order of the certificates must appear exactly as shown; that is, leaf.pem, intermediate1.pem, intermediate2.pem,
intermediaten.pem, root.pem. In the combined.pem file, remove all the carriage returns, line feeds, and new lines from
the certificate string. The final pem file should look similar to the following:

-----BEGIN CERTIFICATE-----
MIIDGjCCAgICFAiW9pIECnqn1L2qTtPaSk5jZB8hMA0GCSqGSIb3DQEBCwUAMCwxCzAJBgNVBAYTAlVTMR0wGw
YDVQQDDBRUZXN0IEludGVybWVkaWF0ZSBDQTAeFw0yMTAzMDUxOTQxNTZaFw0yNjAzMDQxOTQxNTZaMGcxZTAJ
BgNVBAYTAlVTMAoGA1UEChMDRU1DMA8GA1UECxMIU2VjdXJpdHkwEAYDVQQHEwlIb3BraW50b24wEwYDVQQDEw
x3d3cuZGVsbC5jb20wFAYDVQQIEw1NYXNzYWNodXNldHRzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAq+T/lcSDKUmCZwMmgJAMOsPdBFwo4BvIks5+uPrHt5k+Xc82EQCv7v3zQj98l7BDizARM/
uuym29lPa7csZoboITSNZguXoTrPKX5S/q1Zr/C2yREM4ZxlxR52dY/

PowerStore Manager 37
 00gRnyRl5WeMBVYhtHljjpo1CftXTJn/
XzTI+6IWHdhc6y7NwDb58ISIN39n+FSTSMoMJcOJKIfZl36UsJDOzNp+dlD9rSpnPxxGbcvfLEUZYBo48cTr6i
PR2iHQy4mqSY8AzznaNxjmYkrRK9Np02Kucqci5t6v7U4icdfonv3u1j6P3JQvF9POKRGQ6UQnDgYykKr16Hre
7nxrQ6m2L7mvwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAW3HpGIJompQBGTi3sce+DBQhG9FkqVAjv8wMLf6d
6NAwEsSITSb1MMdxZrMLWzNlf3LWMoIY4J17JDoJtQxipFIuubI0dst8gYmMXnD2A2yHvgA2gh3CGljSJBGAWj
dFb0ww+ovDVhz5dD+nWYhqASbBdbp+8e3uzUAalFB8YwJ9/
tgHm4gh020E4FUGB4WPbLfct6gEG46NFlQuv73s7IDgdR00HnslPfu90eILPUmyk36bh6vNkfLf+XFXCL+ROr/
9yoAEWWLl17OdDdNCjGvioyfT6vSE6P2GSqHvauTsVIToZqStnrzjkeZ+OCDltm/OeCJuximz/iv/f+MEq
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIC7jCCAdagAwIBAgIBATANBgkqhkiG9w0BAQsFADAkMQswCQYDVQQGEwJVUzEVMBMGA1UEAwwMVGVzdCBSb2
90IENBMB4XDTIxMDMwNTE5MzUyOVoXDTI5MDUyMjE5MzUyOVowLDELMAkGA1UEBhMCVVMxHTAbBgNVBAMMFFRl
c3QgSW50ZXJtZWRpYXRlIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsekwO9etrShyKf3XMr
LMhNhNmMYfuhoiVZqlKk5iR4NbgrcVQyEVYGJPBidCSniRdhM3J9XFdJ9SeSOlR9d/
tfVN1+Cznui7TeMGhYGNNYcbyOJXHzm92SkacDv8/
mIUxdTTysznlzTrLC8w8lg5HFRZg5PI0LLggTdFbpH6xRd5Weo/
VlRjzG6WYBLzCUvCuPhOPUdLFaOqaqGtEVkz7dOQfSU8Z7x3dl+QvbuDBtJwoebV01UaK2eX9s9AI0BcTcVecs
06Ur8vr91xz5+WhSykHykLXkGfW5Az/
9gXzCaHeuYBxGWUtZfxl22pAgs3VTCnu462loYnJr1l5rFrsQIDAQABoyMwITAPBgNVHRMBAf8EBTADAQH/
MA4GA1UdDwEB/wQEAwICBDANBgkqhkiG9w0BAQsFAAOCAQEAd6emDIsPRwnNsIQQIyX+115fg8O1X9Z/
TAPXDAqEsua/
u3elz1VxkdgAelB8kOiKgMkYhg4MG9AXz14Mwa0rOu3F63XAN8+0YwtW0ybg9JfPSc34woLW5jKsS/
K7RPLFXgrrpvLjjMpyDVNysyE3mmbE1622uktDCCf/+nU0SMnggzGG8M09HI9YdaMv8UmVcq80XJ3giMzpr/
CLXXJvAvA1CZMaVJUCK7sDEWahjYy1IYp7WOKW0DcdJSapCNxxXKsfdAuMOTzygYtzgnE4E/
cK6X9XbLtZeTrCZrPwGQDXRVc+vQollkeQ0idEG7hS1aD1XWNpOR2Y38okHonrDg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIC5jCCAc6gAwIBAgIBADANBgkqhkiG9w0BAQsFADAkMQswCQYDVQQGEwJVUzEVMBMGA1UEAwwMVGVzdCBSb2
90IENBMB4XDTIxMDMwNTE5MzIzMFoXDTMxMDMwMzE5MzIzMFowJDELMAkGA1UEBhMCVVMxFTATBgNVBAMMDFRl
c3QgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMWEBG60yUjrvpGSlLgwqnZvR/
m4RfqAx33EHunXQdblrQ097Gg+x9A862b4YOfzZkdhVZ1ExmBo9sq386Q+IYt723XH12CPdAR6Qu2KTHyBtKpD
xSCG9rIItlOdi1tGqxFnG3w3esqJcUDAkFJc3fUFYp0J8fQAP77aHn4eZmsk7mXpzhe9Mgq6N16vL5BgRq2M44
AxjH/tJ/pLkJCjp0klokQx3vF7jx43FiSU6Tay6x2C04GzWxDG6eI/
FHckf9GucBKPi9waTCZMFx7odB3bSWGBHxOgy6GtyEoVPvXLZguR8/
MxIEGEt25svnbWliIDDSXac9VMJkv1oQZSaP8CAwEAAaMjMCEwDwYDVR0TAQH/BAUwAwEB/
zAOBgNVHQ8BAf8EBAMCAgQwDQYJKoZIhvcNAQELBQADggEBAF5IxYM/
uxrh1Jbp7haBdqKnPZ2UFKB6hqGmpfg6uVeA0NqToNgP4PqyR+3qkCzVuCXSeZ28GKYsw5yQ+xjQAf9LLL39aX
jclhoNJ+SpKOS32S0Bq3Ur9Wk7xyz+FkRDQYKCrDXVMV0skqa0f4rEiHWXO1z1UXnv6BCDDTCzun0TCyAS9/
sxBGT0MKJ3q/
8ptAn+3k0vHtQvQKy6pC1Kx3y0641Vvz5XZ54T2VeEPpuqiQYeKOh5TpzvPa5Xj+T39Lt2lnqaMGYHj9KNtFQf
s3GwYEqB04K3qDm7uIo6LBlGQ87qw9N2YphCkt0eSCnk0Gi0XjDT/j/qQZT/bCWjjrk=
-----END CERTIFICATE-----

12. Import the signed server certificate.

NOTE: Use either the PowerStore CLI or REST API to import the third party CA signed server certificate. The following
is an example of the REST API and 5beb91ac-8bd9-430f-bf7a-dd912396d699 is the ID for the certificate which
was generated in the CSR example in the first step and recorded from the CSR response output:

https://10.0.0.1/api/rest/x509_certificate/5beb91ac-8bd9-430f-bf7a-dd912396d699
(PATCH)

Request body

{
"certificate": "-----BEGIN CERTIFICATE-----
\nMIIDfTCCAmUCFGzw3bUj03AHgNpKmbnETbUHuZSHMA0GCSqGSIb3DQEBCwUAMIGOMQswCQYDVQQGEwJVU
zELMAkGA1UECAwCTUExEjAQBgNVBAcMCUhvcGtpbnRvbjENMAsGA1UECgwERGVsbDEaMBgGA1UECwwRTWlk
cmFuZ2Ugc2VjdXJpdHkxDTALBgNVBAMMBHRlc3QxJDAiBgkqhkiG9w0BCQEWFXJhbmppdC5rb2xsdUBkZWx
sLmNvbTAeFw0yMDEwMjAxODM1MjlaFw0yMTEwMjAxODM1MjlaMGcxZTAJBgNVBAYTAlVTMAoGA1UEChMDRU
1DMA8GA1UECxMIU2VjdXJpdHkwEAYDVQQHEwlIb3BraW50b24wEwYDVQQDEwx3d3cuZGVsbC5jb20wFAYDV
QQIEw1NYXNzYWNodXNldHRzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt2z/VwgbF6/
K2cLv1SEadUq+xT0N9RK3GMf/hCowXyr06A5l7/
pOZhoc28A21FaOGo02ZdIe2xVZFpTsuhZtcVpq+s+ZITjdjCnThMrpMRvAnnvehgKMySohxLEFEC9RfDf5l
suU0EenkWMay0CmsNZViCSNMek0hk0DFyKoGzyI26SB+5eRXFrFrgHYdcn8BDGnoNu0aJN+pLVzgbS8cZ9Q
J2oKNoq3+XSh4vp8dgboGgWzkzPXPba819ogdZ2tXuxpgi7xrOn3yu2TSFHJBbU9alHHwjpT0XvIxtaw/
yMN1Hydv8FH00HF88dDN4KMQnWC+7RbtLmUmsIPR+owiwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQCoNNVJ
zbpIk7BVmMBAP1GmEFRXQcpYZtzpbqgyezJfCWzrWQhOen5Qz4Ss718Cb4jMrCGeTUSttcELoFauGBO9g75
al8sc1pOpikE26w1vjsBrtTjys1GWInSLNESD9NkAtBCNFTcIQMAPyMiDBv/
D8le2Ua49tnEiOTxDWOKAAo+JdZdHQQ6PtAAzWwRb+ok6UNdPq2D/
6vI0o2gwDqWFLnivEFpBac6MqH38DJ/
38m8x7kZMsD1Hin8Zz2oZYpR7vPqbhjmF5GwVZW5vlwV1UTMjs6t2KveHxTbTSdoiwXMU6JZT3NWsBjhJgF

38 PowerStore Manager
 46gG5fCVYNoPBX+7OLfAUSQiUP\n-----END CERTIFICATE-----\n",
"is_current": true
}

The following is an example of the CLII and 0e82aae7-6d56-4e0f-9178-eee1759bf4b3 is the ID for the
certificate which was generated in the CSR example in the first step and recorded from the CSR response output:

pstcli -u admin -p Password123! -d 10.0.0.1 x509_certificate -id

0e82aae7-6d56-4e0f-9178-eee1759bf4b3 set -is_current true -certificate $'-----
BEGIN CERTIFICATE-----
\nMIID+jCCAuKgAwIBAgIBFjANBgkqhkiG9w0BAQsFADAsMQswCQYDVQQGEwJVUzEdMBsGA1UEAwwUVGVzd
CBJbnRlcm1lZGlhdGUgQ0EwHhcNMjEwNDI2MTcyODA2WhcNMjQwMTIxMTcyODA2WjBdMQswCQYDVQQGEwJV
UzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEMMAoGA1UEChMDRU1DMREwDwYDVQQLEwhzZWN1cml0eTEVMBM
GA1UEAxMMd3d3LmRlbGwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyDtENt124YxVW2
RsqGGaKnuwOxdaLSTSjdCyXFnOhNmd4N+fBPrtmxY5BJENlCggAcObA1YKIIiuwIhfR7JOnzm8gGnMB06e+
UClLV9mAxMRO5/
dg0upO+qW32VZWQCI7FjyL8L5xQ+BWDlunPOj9FYNzxgeetmxKZ2JIykiyFEXZj49PIEhr/
QKZEg8NfiF7JbHViK/dPCRQaAGqjZWIrluZzV4yueFUA1V/
mfkmbMvgAYsOg6G1224LlM3lCW920CoNQvYVvBJ/OubVxjAnNL2IVvaDv2eriWtED/A/
7SM6ir3nmhp8I65cKJv/
BTbZnJIDmfN5yeHt+ZtRIr0owIDAQABo4H1MIHyMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgZAMDMG
CWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBTZXJ2ZXIgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFM5
5k1ELGKzYsjVfZZSHFenmuZ/
CMDYGA1UdIwQvMC2hKKQmMCQxCzAJBgNVBAYTAlVTMRUwEwYDVQQDDAxUZXN0IFJvb3QgQ0GCAQEwDgYDVR
0PAQH/
BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCEGA1UdEQQaMBiHBAr0HA6HEP2ONkOWEwAAAgFEK76kEgk
wDQYJKoZIhvcNAQELBQADggEBAGT6k9N9Y45JXpV0Cl9lVg9z85UxrqbOZnLSuszyc09xGfK55JJFIaXnJF
tRcQ/
BTNv+G7FkeJws252k0331Hm9khjpyDkQHOEz6SIlnMxbpFRgPHYncJ7kYOkbVTAQV2irvinbDmsfeocDTY8
g4VJ3/bEWjLX4VEbyCSQHKCCkn3z5o1arxXQGOrVSWakD/RtDu3y5cr+/A/
2vPh+yo8/1N8lJiT6EOwbGb6yzMC9Jm/UVG+2b+I+8T9d0/
gk6SuO0u8eT6zDRLVjp3ILyS8v18VMwq7Q5RQ0b/l/g5oPvrHsTvMi/
82657R1tgncPvNu0ltSYjxWXSPvrnFvf7a1g=\n-----END CERTIFICATE-----\n-----BEGIN
CERTIFICATE-----
\nMIIC7jCCAdagAwIBAgIBATANBgkqhkiG9w0BAQsFADAkMQswCQYDVQQGEwJVUzEVMBMGA1UEAwwMVGVzd
CBSb290IENBMB4XDTIxMDMwNTE5MzUyOVoXDTI5MDUyMjE5MzUyOVowLDELMAkGA1UEBhMCVVMxHTAbBgNV
BAMMFFRlc3QgSW50ZXJtZWRpYXRlIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsekwO9e
trShyKf3XMrLMhNhNmMYfuhoiVZqlKk5iR4NbgrcVQyEVYGJPBidCSniRdhM3J9XFdJ9SeSOlR9d/
tfVN1+Cznui7TeMGhYGNNYcbyOJXHzm92SkacDv8/
mIUxdTTysznlzTrLC8w8lg5HFRZg5PI0LLggTdFbpH6xRd5Weo/
VlRjzG6WYBLzCUvCuPhOPUdLFaOqaqGtEVkz7dOQfSU8Z7x3dl+QvbuDBtJwoebV01UaK2eX9s9AI0BcTcV
ecs06Ur8vr91xz5+WhSykHykLXkGfW5Az/
9gXzCaHeuYBxGWUtZfxl22pAgs3VTCnu462loYnJr1l5rFrsQIDAQABoyMwITAPBgNVHRMBAf8EBTADAQH/
MA4GA1UdDwEB/wQEAwICBDANBgkqhkiG9w0BAQsFAAOCAQEAd6emDIsPRwnNsIQQIyX+115fg8O1X9Z/
TAPXDAqEsua/
u3elz1VxkdgAelB8kOiKgMkYhg4MG9AXz14Mwa0rOu3F63XAN8+0YwtW0ybg9JfPSc34woLW5jKsS/
K7RPLFXgrrpvLjjMpyDVNysyE3mmbE1622uktDCCf/
+nU0SMnggzGG8M09HI9YdaMv8UmVcq80XJ3giMzpr/
CLXXJvAvA1CZMaVJUCK7sDEWahjYy1IYp7WOKW0DcdJSapCNxxXKsfdAuMOTzygYtzgnE4E/
cK6X9XbLtZeTrCZrPwGQDXRVc+vQollkeQ0idEG7hS1aD1XWNpOR2Y38okHonrDg==\n-----END
CERTIFICATE-----\n-----BEGIN CERTIFICATE-----
\nMIIC5jCCAc6gAwIBAgIBADANBgkqhkiG9w0BAQsFADAkMQswCQYDVQQGEwJVUzEVMBMGA1UEAwwMVGVzd
CBSb290IENBMB4XDTIxMDMwNTE5MzIzMFoXDTMxMDMwMzE5MzIzMFowJDELMAkGA1UEBhMCVVMxFTATBgNV
BAMMDFRlc3QgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMWEBG60yUjrvpGSlLg
wqnZvR/
m4RfqAx33EHunXQdblrQ097Gg+x9A862b4YOfzZkdhVZ1ExmBo9sq386Q+IYt723XH12CPdAR6Qu2KTHyBt
KpDxSCG9rIItlOdi1tGqxFnG3w3esqJcUDAkFJc3fUFYp0J8fQAP77aHn4eZmsk7mXpzhe9Mgq6N16vL5Bg
Rq2M44AxjH/tJ/pLkJCjp0klokQx3vF7jx43FiSU6Tay6x2C04GzWxDG6eI/
FHckf9GucBKPi9waTCZMFx7odB3bSWGBHxOgy6GtyEoVPvXLZguR8/
MxIEGEt25svnbWliIDDSXac9VMJkv1oQZSaP8CAwEAAaMjMCEwDwYDVR0TAQH/BAUwAwEB/
zAOBgNVHQ8BAf8EBAMCAgQwDQYJKoZIhvcNAQELBQADggEBAF5IxYM/
uxrh1Jbp7haBdqKnPZ2UFKB6hqGmpfg6uVeA0NqToNgP4PqyR+3qkCzVuCXSeZ28GKYsw5yQ+xjQAf9LLL3
9aXjclhoNJ+SpKOS32S0Bq3Ur9Wk7xyz+FkRDQYKCrDXVMV0skqa0f4rEiHWXO1z1UXnv6BCDDTCzun0TCy
AS9/sxBGT0MKJ3q/
8ptAn+3k0vHtQvQKy6pC1Kx3y0641Vvz5XZ54T2VeEPpuqiQYeKOh5TpzvPa5Xj+T39Lt2lnqaMGYHj9KNt
FQfs3GwYEqB04K3qDm7uIo6LBlGQ87qw9N2YphCkt0eSCnk0Gi0XjDT/j/qQZT/bCWjjrk=\n-----END
CERTIFICATE-----'

For information about the associated REST API command, see the PowerStore REST API Reference Guide. For
information about the associated CLI command, see the PowerStore CLI User Guide. In PowerStore Manager, the

PowerStore Manager 39
 server certificate signed by the third party CA should appear and replace the self-signed PowerStore CA certificate for
the Management HTTP service upon the successful completion of the certificate import.

13. Verify the imported CA signed server certificate.

NOTE: Open a browser and click on the lock symbol. Verify that the certificate and the issuer of the certificate are valid
and correct.

Third party Certificate Authority signed server certificate restrictions and

limitations
The following restrictions and limitations apply to PowerStore operating system version 2.1.x for a third party CA signed server
certificate import. These restrictions and limitations do not apply to PowerStore operating system versions 3.0 or later.
● Only supported using either the PowerStore CLI or Rest API.
● The PowerStore CLI commands that are used in importing a third party CA signed server certificate must be run in
nonsession mode.
● For new PowerStore systems, the third party CA signed server certificate import process must be completed successfully
before setting up the systems for replication.
● If existing systems have not been set up for replication after upgrading to PowerStore operating system version 2.1, third
party CA signed server certificate import is supported.
● If existing systems have active replication occurring between their systems before upgrading to PowerStore operating
system version 2.1, third party CA signed server certificate import is not supported.
NOTE: Third party CA signed server certificate import should occur before establishing the replication connection, and
before the certificate exchange with the remote system for replication.
● Only PowerStore appliances that are block-optimized are supported.
● A multiappliance cluster is not supported.
● Third party CA signed server certificate import is only supported for Management traffic (Management_HTTP).
● Certificates must be valid for at least 30 days.
● Reverting to self-signed (PowerStore CA) certificates is not supported.
● No alert for certificate expiration.

Third party Certificate Authority signed server certificate renewal

In case the server certificate for the Management HTTP service has expired or must be renewed, use one of the following work
flows to import a new third party Certificate Authority (CA) signed server certificate:
● If the local cluster is in a replication relationship with another cluster:
NOTE: Most likely the management connection is broken between the two clusters. Even if the management
connection does not appear as broken, the connection status is updated as broken once a new TLS connection is
established.
1. Run the PowerStore CLI reset _certificates command to reset the server certificate of the local cluster to the
default PowerStore CA signed server certificate.

pstcli -user <<username>> -password <<Password>> -destination localClusterIP /

x509_certificate reset_certificates -service Management_HTTP

2. Run the PowerStore CLI exchange command to reestablish the replication management connection. Ensure that the
replication connection is recovered.

pstcli -user admin -password <<Password>> -destination localClusterIP

/x509_certificate exchange -address remoteClusterIP -port 443 -service
Replication_HTTP -username <<username>> -password <<Password>>

3. In PowerStore Manager, generate a Certificate Signing Request (CSR) to import a third-party CA-signed server
certificate. See Generate a Certificate Signing Request.
4. In PowerStore Manager, import a signed cluster certificate. See Import a third party Certificate Authority signed server
certificate.
● If the local cluster is not in a replication relationship with another cluster:

40 PowerStore Manager
 1. In PowerStore Manager, generate a CSR to import a third-party CA-signed server certificate. See Generate a Certificate
Signing Request.
2. In PowerStore Manager, import a signed cluster certificate. See Import a third party Certificate Authority signed server
certificate.

Third party Certificate Authority signed server certificate CA certificate

renewal
In case the CA has expired or has been compromised and must be renewed, use this workflow to import a new third party
CA-signed server certificate:
● If the local cluster is in a replication relationship with another cluster:
NOTE: Most likely the management connection is broken between the two clusters. Even if the management
connection does not appear as broken, the connection status is updated as broken once a new TLS connection is
established.
1. Run the PowerStore CLI reset _certificates command to reset the server certificate of the local cluster to the
default PowerStore CA signed server certificate.

pstcli -user <<username>> -password <<Password>> -destination localClusterIP /

x509_certificate reset_certificates -service Management_HTTP

2. Run the PowerStore CLI exchange command to reestablish the replication management connection. Ensure that the
replication connection is recovered.

pstcli -user admin -password <<Password>> -destination localClusterIP

/x509_certificate exchange -address remoteClusterIP -port 443 -service
Replication_HTTP -username <<username>> -password <<Password>>

3. In PowerStore Manager, generate a Certificate Signing Request (CSR) to import a third-party CA-signed server
certificate. See Generate a Certificate Signing Request.
4. In PowerStore Manager, import a signed cluster certificate. See Import a third party Certificate Authority signed server
certificate.
● If the local cluster is not in a replication relationship with another cluster:
1. In PowerStore Manager, generate a CSR to import a third-party CA-signed server certificate. See Generate a Certificate
Signing Request.
2. In PowerStore Manager, import a signed cluster certificate. See Import a third party Certificate Authority signed server
certificate.

Importing a third party CA-signed server certificate due to cluster IP

address change
If the cluster IP address changes when a third party CA-signed server certificate is in use for the Management HTTP service,
use the following workflow to import a third party CA-signed server certificate:
1. (Only applies for replicating systems) If replication has been set up between systems, the remote system that is set up as
part of the replication must be deleted first.
NOTE: See the PowerStore Protecting Your Data Guide for detailed information about deleting a remote system.
2. Reconfigure the cluster IP address.
NOTE: See the PowerStore Manager online help or the PowerStore T and Q Networking Guide for Storage Services
for information about how to reconfigure network settings. Also, the cluster server certificate for Management_HTTP
resets back to the PowerStore CA-signed certificate as part of the operation to reconfigure the cluster IP address. You
must reimport the third party CA-signed server certificate.
3. Reimport the third party CA-signed server certificate.
● For PowerStore operating system version 3.0 or later, generate a CSR and import the signed cluster certificate. See
Generate a Certificate Signing Request and Import a signed cluster certificate, respectively.
● For PowerStore operating system version 2.1.x, see Import a third party Certificate Authority signed server certificate.

PowerStore Manager 41
 NOTE: In PowerStore Manager, the server certificate that is signed by the new third party CA should appear. This
server certificate replaces the PowerStore CA-signed certificate for the Management HTTP service upon the successful
completion of the certificate import.
4. (Only applies for replicating systems) Readd the systems for replication after the third party CA-signed server certificate has
been imported successfully.
NOTE: See the PowerStore Protecting Your Data Guide for detailed information.
5. (Only applies for replicating systems) Reestablish the remote replication sessions.
NOTE: See the PowerStore Protecting Your Data Guide for detailed information.

Secure communication between PowerStore

appliances within a cluster
During cluster creation, the primary node of the cluster master appliance creates a certificate authority (CA) certificate, also
known as the cluster CA. The master appliance passes the cluster CA certificate to the appliances joining the cluster.
Each PowerStore appliance in a cluster generates its own unique IPsec certificate which is signed by the cluster CA certificate.
The sensitive data that PowerStore appliances transmit over their cluster network are protected by IPsec and TLS so that the
security and integrity of the data is preserved.

Secure communication for replication and data import

PowerStore's certificate and credential infrastructure allows the exchange of server and client certificates, and user credentials.
This process includes:
● Retrieving and validating server certificate during TLS handshake
● Adding the trusted CA certificate from the remote system to the credential store
● Adding the trusted server/client certificate to the credential store
● Assisting in establishing secure connections once the trust is established
PowerStore supports the following certificate management functionality:
● For replication, a certificate exchange between two PowerStore clusters to establish trusted management communication.
To facilitate replication between PowerStore clusters, bi-directional trust must be established between the clusters to allow
for mutual TLS authentication when issuing replication REST control requests.
● For data import, a certificate and credentials exchange with persistence, to establish a secure connection between a Dell
storage system (a VNX, Unity, Storage Center (SC), or a Peer Storage (PS) system) and a PowerStore cluster.

VASA certificate
PowerStore operating system versions 3.5 and later support the import and use of a user provided, third-party Certificate
Authority (CA) signed certificate. This CA signed certificate is used to replace the self-signed certificate that PowerStore VASA
uses.
As part of this feature, you can do the following through either the PowerStore Manager, REST API, or CLI:
● Generate a Certificate Signing Request (CSR).
● Import a CA signed certificate.
● Select to retain the imported CA signed certificate so that it does not get overwritten by the vCenter server.
For information about configuring a vCenter server connection to PowerStore, see the related PowerStore Online Help or the
PowerStore Virtualization Infrastructure Guide.

42 PowerStore Manager
Generate a Certificate Signing Request
Prerequisites
Before you generate a Certificate Signing Request (CSR), ensure that you have obtained the following information for the
request:
● Common Name
● IP address
● DNS Name (optional)
● Organization
● Organization Unit
● Locality
● State
● Country
● Key Length

About this task

Generating a CSR is applicable to a Mutual Authentication Certificate, which is used in two-way authentication between
PowerStore and the VASA server. To generate a CSR using the PowerStore Manager, do the following:

Steps
1. Select Settings and under Security select VASA Certificate.
The VASA Certificate page appears.
2. Select Generate CSR.
The Generate CSR slide out appears.
3. Type in the information that is used to generate the CSR.
4. Click Generate.
The Generate CSR slide out changes to show the next steps that must be taken along with the certificate text.
5. Click Copy to clipboard to copy the certificate text to your clipboard.
6. Click Close.
7. The certificate authority (CA) must sign the certificate so that it can be imported as a Mutual Authentication Certificate.

Import a third party Certificate Authority signed server certificate

for VASA Provider
Prerequisites
Before importing a third party Certificate Authority (CA) signed server certificate, ensure the following:
● A Certificate Signing Request (CSR) file was generated, downloaded and sent to the third party CA server for signing.
● The CA has signed the certificate so that it can be imported as a Mutual Authentication Certificate.
● Your vCenter trusts the CA of the certificate being imported, otherwise VASA functionality will be unavailable.
● You know the location of the certificate file or have the certificate text available to copy and paste for import.
● The certificate or certificate chain is formatted properly, See Format of a certificate or certificate chain before importing it.

About this task

To import a certificate using the PowerStore Manager, do the following:

Steps
1. Click Settings and, under Security, select VASA Certificate.
The VASA Certificate page appears.
2. To prevent the VASA server certificate from being overwritten by the vCenter, ensure the Enable/Disable toggle is set to
Enabled.
3. Select Import.

PowerStore Manager 43
 The Import Server Certificate slide out appears.
4. Do one of the following:
● Select Select Certificate File, then locate and select the file to import.
● Select Paste Certificate Text, then copy and paste the certificate text in the text box.
5. Select Import.
The certificate detail information should appear in the VASA Certificate page. Also, the VASA entry appearing on the
Certificate page (Settings > Security > Certificate) should be identified by the Service as VASA_HTTP and Scope as
vasa.

vSphere Storage API for Storage Awareness support

vSphere Storage API for Storage Awareness (VASA) is a VMware-defined, vendor-neutral API for storage awareness. A VASA
Provider consists of multiple components working in cooperation to service incoming VASA API requests. The VASA API
gateway, which receives all incoming VASA APIs, is deployed on the primary appliance (the appliance that owns the floating
management IP) in a PowerStore cluster. ESXi hosts and vCenter Server connect to the VASA Provider and obtain information
about available storage topology, capabilities, and status. After the vCenter Server provides this information to vSphere clients,
VMware clients use VASA rather than PowerStore Manager clients.
The vSphere user must configure the VASA Provider instance as the provider of VASA information for the cluster. If the lead
appliance goes down, the related process will restart on the appliance that becomes the next primary, along with the VASA
Provider. The IP address fails over automatically. Internally, the protocol sees a fault when obtaining configuration change
events from the newly active VASA Provider, but this fault causes an automatic resynchronization of the VASA objects without
user intervention.
The PowerStore provides VASA 3.0 and 4.0 interfaces for vSphere. See the PowerStore Simple Support Matrix document at
dell.com/powerstoredocs for ESXi and vSphere compatibility information.
VASA 3.0 and VASA 4.0 support Virtual Volumes (vVols). VASA 3.0 and VASA 4.0 support interfaces to query storage
abstractions such as vVols and Storage Containers. This information helps storage policy-based management (SPBM) determine
virtual drive placement and compliance. VASA 3.0 and VASA 4.0 also support interfaces to provision and manage the life cycle
of vVols used to back up virtual drives. ESXi hosts directly invoke these interfaces.
For more information related to VASA, vSphere, and vVols, see the VMware documentation and the PowerStore Manager online
help.

Authentication related to VASA

During the initial configuration of a PowerStore cluster, a connection to a vCenter Server and PowerStore VASA provider are
optional. Establishing a connection to a vCenter Server and registering a VASA provider can be performed after the initial
configuration of a PowerStore cluster is complete.
NOTE: PowerStore clusters can host traditional (VMFS) datastores without being registered as a VASA provider or
connecting to a vCenter Server. However, registering a PowerStore VASA provider in vCenter Server is required to use
vVols.
To manually establish an initial connection to a vCenter server and to register a PowerStore VASA provider in a vCenter Server,
use the vSphere client to enter the following information to configure a connection to the PowerStore cluster:
● Name (can be any name that you choose)
● URL of the VASA Provider, using the following format for VASA 3.0 or VASA 4.0: https://<Management IP address>:8443/
version.xml
● Username of a PowerStore user (the role of this user must be either VM Administrator or Administrator)
NOTE: A PowerStore user with the VM Administrator role is strictly used as a means to register certificates. A
PowerStore user with an Administrator role can perform additional tasks. See Roles and privileges for more details.
○ For local users use the syntax: local/<username>
○ For LDAP users use the syntax: <domain>/<username>
● Password associated with the PowerStore user.
NOTE: The PowerStore user credentials that are used here are only used during this initial step of the connection.

On the PowerStore cluster, use the PowerStore Manager to enter the following information:
● IP address or FQDN of the vCenter

44 PowerStore Manager
● Username of the vCenter
● Password associated with the vCenter.
● (Applicable only to PowerStore operating system version 4.x and later) Verify SSL server certificate (the vCenter machine
certificate)
NOTE: This option is selected by default, and it is recommended to verify the SSL server certificate. Verifying the SSL
server certificate provides enhanced security. The machine SSL certificate appears in vCenter as __Machine_Cert. See
the VMware documentation for more information.
○ When this option is selected, PowerStore downloads the SSL certificate. You can either view the SSL certificate for
verification and confirm its authenticity, or you can cancel the verification operation. If you confirm the verification
operation and the user credentials are valid for the connection to the destination cluster, the certificate of the
vCenter Server is stored and the vCenter is registered with the cluster. If you cancel the verification operation, the
vCenter Server Configuration fields appear again but the certificate of the vCenter Server is not stored and the
vCenter is not registered with the cluster.
○ When this option is not selected and the PowerStore user credentials are valid for the connection to the destination
cluster, the certificate of the vCenter Server is automatically downloaded without user verification, and the vCenter
is registered with the cluster. Like PowerStore operating system version 3.6.x or earlier, no manual steps are required
to install or upload this certificate to the VASA Provider.
● Username of a PowerStore user (the role must be either VM Administrator or Administrator)
● Password associated with the PowerStore user
NOTE: The certificate of the vCenter Server is used to authenticate all subsequent requests from the vCenter. If the
certificate has expired, the vCenter must register a new certificate to support a new session. If the user revokes the
certificate, the session is invalidated and the connection is severed.

vCenter session, secure connection, and credentials

A vCenter session begins when a vSphere administrator uses the vSphere Client to supply the vCenter Server with the VASA
Provider URL and login credentials. The vCenter Server uses the URL, credentials, and the SSL certificate of the VASA Provider
to establish a secure connection with the VASA Provider. A vCenter session ends when one of the following events occurs:
● An administrator uses the vSphere Client to remove the VASA Provider from the vCenter configuration, and the vCenter
Server terminates the connection.
● The vCenter Server fails or a vCenter Server service fails, terminating the connection. If vCenter or the vCenter Server
service cannot reestablish the SSL connection, it starts a new session.
● The VASA Provider fails, terminating the connection. When the VASA Provider starts up, it can respond to communication
from the vCenter Server to reestablish the SSL connection and VASA session.
A vCenter session is based on secure HTTPS communication between a vCenter Server and a VASA Provider. In VASA 3.0,
the vCenter Server acts as the VMware certificate authority (VMCA). The VASA Provider transmits a self‐signed certificate
on request, after authorizing the request. With PowerStore operating system version 4.x or later, you have the option to
verify the downloaded SSL server certificate of the vCenter. This option is selected by default. When this option is selected
and to continue and register the vCenter, you must confirm that the thumbprint (also known as a fingerprint) and certificate
information are correct. While reviewing the thumbprint and certificate information, you can also select to view the certificate.
The information should match the certificate of the vCenter. After you verify and confirm the thumbprint and certificate
information, the vCenter is registered with PowerStore and the certificate is stored in the truststore of PowerStore. However,
if the verify option is cleared, PowerStore follows the same processing as PowerStore operating system version 3.6.x or earlier.
PowerStore adds the VMCA certificate to its truststore, then issues a certificate signing request, and replaces its self‐signed
certificate with the VMCA signed certificate, which has not been verified by the user.
NOTE: After the downloaded SSL server certificate of the vCenter has been confirmed and stored, changing the hostname
of the vCenter server may impact the connection between PowerStore and the vCenter. The change in hostname may
modify the machine SSL certificate and the VMCA root certificate. The certificates then become untrusted by PowerStore.
See the PowerStore Virtualization Infrastructure Guide for information about restoring a vCenter and VASA Provider
connection.
Future connections between the vCenter Server and a VASA Provider will be authenticated by the VASA Provider using the
client Storage Monitoring Service (SMS) certificate that is validated against the previously registered leaf certificate or root
signing certificate. A VASA Provider generates unique identifiers for storage entity objects, and the vCenter Server uses the
identifier to request data for a specific entity.

PowerStore Manager 45
A VASA Provider uses SSL certificates and the VASA session identifier to validate VASA sessions. After the session is
established, a VASA Provider must validate both the SSL certificate and the VASA session identifier that is associated with
each function call from the vCenter Server. The VASA Provider uses the VMCA trusted root certificates that are stored in
its truststore to validate the certificate associated with function calls from the vCenter SMS. A VASA session persists across
multiple SSL connections. If an SSL connection is dropped, the vCenter Server performs an SSL handshake with the VASA
Provider to re‐establish the SSL connection within the context of the same VASA session. If an SSL certificate expires,
the vSphere administrator must generate a new certificate. The vCenter Server then establishes a new SSL connection and
registers the new certificate with the VASA Provider.
CAUTION: SMS does not call the unregisterVASACertificate function against a 3.0 VASA Provider.
Therefore, even after unregistration, the VASA Provider can continue to use its VMCA signed certificate that
was obtained from the SMS.

iSCSI CHAP authentication

Challenge Handshake Authentication Protocol (CHAP) is a method of authenticating iSCSI initiators (hosts) and targets
(volumes and snapshots). CHAP exposes iSCSI storage, and ensures a secure, standard storage protocol. Authentication
depends on a secret, which is similar to a password that is known to both the authenticator and the peer. There are two
variants of the CHAP protocol:
● Single CHAP authentication allows for the iSCSI target to authenticate the initiator. When an initiator tries to connect to a
target (Normal mode or through Discovery mode), it provides a username and password to the target.
● Mutual CHAP authentication is applied in addition to single CHAP. Mutual CHAP allows for the iSCSI target and the initiator
to authenticate each other. The iSCSI initiator authenticates each iSCSI target that the group presents. When an initiator
tries to connect to a target, the target provides a username and password to the initiator. The initiator compares the
supplied username and password to the information that it holds. If they match, the initiator can connect to the target.
NOTE: If your environment uses CHAP, it is recommended that you set up and enable CHAP authentication before
preparing volumes to receive data. If you prepare drives to receive data before you set up and enable CHAP authentication,
you could lose access to the volumes.
PowerStore does not support iSCSI CHAP Discovery mode. The following table shows the limitations of PowerStore related to
iSCSI CHAP Discovery mode.

Table 8. iSCSI CHAP Discovery mode limitations

CHAP Mode Single Mode (initiator enabled) Mutual Mode (initiator and target
enabled)
Discovery PowerStore does not authenticate PowerStore does not respond to
(challenge) the host. Authentication an authentication request (challenge)
cannot be used to preclude the from a host. If the host challenges
discovery of targets. This action does PowerStore, discovery fails.
not result in unintended access to user
data.
Normal Authentication works as expected. Authentication works as expected. Both
PowerStore tests the credentials. PowerStore and the host test the
credentials.

For remote replication between a source and target appliance, the verify and update process detects changes in the local and
remote systems and reestablishes data connections. The CHAP settings are also considered in the process.

Configuring CHAP
CHAP single (initiator enabled) or mutual (initiator and target) authentication can be enabled on a PowerStore cluster. CHAP
can be enabled for a cluster implementation of one appliance or multiple PowerStore appliances and external hosts.
When single authentication is enabled, the username and password for each initiator are required to be entered when external
hosts are added. When mutual authentication is enabled, the username and password for the cluster are also required to be
entered. When adding a host and adding initiators with CHAP enabled, the initiator password must be unique, you cannot use
the same password across the initiators of a host. Specific details on how to configure the CHAP configuration of an external
host varies. To utilize this capability, you need to be familiar with the operating system of the host and how to configure it.

46 PowerStore Manager
 NOTE: Enabling CHAP once hosts are configured on the system is a disruptive action for the external hosts. It causes I/O
interruption until configurations are set up on both the external host and appliance. It is recommended that, before adding
external hosts to the appliance, you decide what type of CHAP configuration you want to implement, if any.
If you enable CHAP after hosts are added, update each host's initiators. If CHAP is enabled, you cannot add a host to a host
group that does not have CHAP credentials. Once CHAP is enabled and you add a host later, manually register the host in
the PowerStore Manager, under Compute select Hosts & Host Groups. You need to enter credentials at the iSCSI level for
authentication use. In this case, copy the IQN from the host and then add the related CHAP credentials for each initiator.
Configure CHAP for a cluster through any of the following means:
● iSCSI CHAP - A CHAP settings page that you can access from the PowerStore Manager (click Settings and under
Security select iSCSI CHAP).
● REST API server - Application interface that can receive REST API requests to configure CHAP settings. For more
information about the REST API, refer to the PowerStore REST API Reference Guide.
To determine the status of CHAP, in the PowerStore Manager, click Settings and under Security select iSCSI CHAP.

External SSH access

Each appliance can optionally enable external secure shell (SSH) access to the SSH port of the appliance IP address, which
takes the user to the service feature on the primary node of an appliance. The appliance IP address floats between the two
nodes of the appliance as the primary designation changes. If external SSH is disabled, SSH access is disallowed.
When an appliance first comes up and is not configured, SSH is enabled by default so that the appliance can be serviced if
issues are encountered before it is added to a cluster. When a new cluster is created or for a join cluster operation, all appliances
should have SSH initially set to disabled.

Configuring external SSH access

Configure external SSH access to appliances within a cluster by using any of the following means:
● SSH Management – A SSH settings page that you can access from the PowerStore Manager (click Settings and under
Security select SSH Management).
● REST API server – Application interface that can receive REST API requests to configure SSH settings. For more
information about the REST API, see the PowerStore REST API Reference Guide.
● svc_service_config – A service command that you can enter directly as the service user on the appliance. For more
information about this command, see the PowerStore Service Scripts Guide.
To determine the status of SSH on appliances within a cluster, in the PowerStore Manager, click Settings and under Security
select SSH Management. You can also enable or disable SSH on one or more appliances that you select.
Once the SSH service has been successfully enabled, use any SSH client to log in to the appliance IP address. Accessing the
appliance requires service user credentials.
The service account enables users to perform the following functions:
● Perform specialized appliance service scripts for monitoring and troubleshooting appliance system settings and operations.
● Operate only a limited set of commands that are assigned as a member of a non-privileged Linux user account in restricted
shell mode. This account does not have access to proprietary system files, configuration files, or user or customer data.
For maximum appliance security, it is recommended to always leave the external SSH service interface disabled unless it must
be used to perform service operations on the appliance. After performing the necessary service operations, disable the SSH
interface to ensure that the appliance remains secure.

SSH sessions
The PowerStore SSH service interface sessions are maintained according to the settings established by the SSH client. Session
characteristics are determined by the SSH client configuration settings.

Service account password

The service account is an account that service personnel can use to perform basic Linux commands.

PowerStore Manager 47
During initial configuration of the appliance, you must change the default service password. The service password restrictions
are the same as those that apply to the System management accounts (see Username and password usage).

SSH authorization
Service account authorization is based on the following:
● Application isolation – PowerStore software uses container technology that provides application isolation. Appliance service
access is provided by the service container, only a set of service scripts and a set of Linux commands are available. The
service account does not have the ability to access other containers which serve file system and block I/O to users.
● Linux file system permissions – Most Linux tools and utilities that modify system operation in any way are not available
for the service user, it requires superuser account privileges. Since the service account does not have such access rights,
the service account cannot use Linux tools and utilities to which it does not have execute permissions and cannot edit
configuration files that require root access to read or modify, or both.
● Access controls – Besides application isolation provided by container technology, the access control list (ACL) mechanism
on the appliance uses a list of very specific rules to explicitly grant or deny access to system resources by the service
account. These rules specify service account permissions to other areas of the appliance that are not otherwise defined by
standard Linux file system permissions.

Appliance service scripts

A set of problem diagnostic, system configuration, and system recovery scripts are installed on the appliance's software version.
These scripts provide an in-depth level of information and a lower level of system control than is available through PowerStore
Manager. The PowerStore Service Scripts Guide describes these scripts and their common use cases.

Appliance node Ethernet service port and IPMItool

Your appliance provides console access over an Ethernet service port that is on each node. This access requires the use of the
IPMItool. The IPMItool is a network tool similar to SSH or Telnet that interfaces with each node over an Ethernet connection by
using the IPMI protocol. The IPMItool is a Windows utility that negotiates a secure communication channel to access the node
console of an appliance. This utility requires physical access to activate the console.
The node Ethernet service port interface provides the same functions and features as the service SSH interface (Service LAN
interface). Also, it is subject to the same restrictions. However, users access the interface through an Ethernet port connection
rather than an SSH client. This interface is designed for field service personnel who can connect to the appliance without having
to disturb your network. A dedicated management console is not necessary.
This interface provides a direct point-to-point, nonroutable connection. Service personnel can use the Service LAN interface for
console output, SSH access to the PowerStore Service Container and PowerStore Manager including the Initial Configuration
Wizard (ICW). SSH access to the Service Container through the Service LAN interface is always enabled, and cannot be
disabled; however, you manage the service account credential.
For a list of service scripts, see the PowerStore Service Scripts Guide.

NFS secure
NFS secure is the use of Kerberos for authenticating users with NFSv3 and NFSv4. Kerberos provides integrity (signing) and
privacy (encryption). Integrity and privacy are not required to be enabled, they are NFS export options.
Without Kerberos, the server relies entirely on the client to authenticate users: the server trusts the client. With Kerberos this is
not the case, the server trusts the Key Distribution Center (KDC). It is the KDC which handles the authentication and manages
accounts (principals) and passwords. Moreover, no password in any form is sent on the wire.
Without Kerberos, the user identifier (UID) of the user is sent on the wire un-encrypted and thus can easily be spoofed. With
Kerberos, the identity (principal) of the user is included in the encrypted Kerberos ticket, which can only be read by the target
server and KDC. They are the only ones to know the encryption key.
In conjunction with NFS secure, AES128 and AES256 encryption in Kerberos is supported. Along with NFS secure, this also
impacts SMB and LDAP. These encryptions are now supported by default by Windows and Linux. These new encryptions are
much more secure; however, it is up to the client whether they are used. From that user principal, the server builds the
credential of that user by querying the active Unix Directory Service (UDS). Since NIS is not secured, it is not recommended to
use it with NFS secure. It is recommended to use Kerberos with LDAP or LDAPS.

48 PowerStore Manager
NFS secure can be configured through PowerStore Manager.

File protocol relationships

With Kerberos the following is required:
● DNS - You must use DNS name in place of IP addresses.
● NTP - PowerStore must have a configured NTP server.
NOTE: Kerberos relies on the correct time synchronization between the KDC, servers, and client on the network.
● UDS - To build credentials.
● Hostname - Kerberos works with names and not IP addresses.
NFS secure uses one or two service principal names (SPNs) depending on the value of the hostname. If the hostname is in
FQDN format host.domain:
● The short SPN: nfs/host@REALM
● The long SPN: nfs/host.domainFQDN@REALM
If the hostname is not in FQDN format, only the short SPN will be used.
Similar to SMB, where an SMB server can be joined to a domain, an NFS server can be joined to a realm (the Kerberos
equivalent term for domain). There are two options for this:
● Use the configured Windows domain if any
● Entirely configure a UNIX KDC based Kerberos realm
If the administrator selects to use the configured Windows domain, there is nothing else to do. Every SPN used by the NFS
service is automatically added/removed into the KDC when joining/unjoining the SMB server. Note that the SMB server cannot
be destroyed if NFS secure is configured to use the SMB configuration.
If the administrator selects to use a UNIX based Kerberos realm, more configuration is needed:
● Realm name: The name of the Kerberos realm, which generally contains all upper-case letters.
● Entirely configure a UNIX KDC based Kerberos realm.
To ensure that a client mounts an NFS export with a specific security, a security parameter, sec, is provided that indicates
which minimal security is allowed. There are 4 kinds of security:
● AUTH_SYS: Standard legacy security which does not use Kerberos. The server trust the credential provided by the client
● KRB5: Authentication using Kerberos v5
● KRB5i: Kerberos authentication plus integrity (signing)
● KRB5p: Kerberos authentication plus integrity plus privacy (encryption)
If a NFS client tries to mount an export with a security that is lower than the configured minimal security, the access will be
denied. For example, if minimal access is KRB5i, any mount using AUTH_SYS or KRB5 will be rejected.

Building a credential
When a user connects to the system, it presents only its principal, user@REALM, which is extracted from the Kerberos ticket.
Unlike AUTH_SYS security, the credential is not included in the NFS request. From the principal, the user part (before the @)
is extracted and used to lookup the UDS for the corresponding uid. From that uid, the credential is built by the system using
the active UDS, similar to when the Extended NFS credential is enabled (with the exception that, without Kerberos, the uid is
provided directly by the request).
If the principal is not mapped in the UDS, the configured default UNIX user credential is used instead. If the default UNIX user is
not set, the credential used will be nobody.

Security on file system objects

In a multiprotocol environment, security policy is set at the file system level, and is independent for each file system. Each file
system uses its access policy to determine how to reconcile the differences between NFS and SMB access control semantics.
Selecting an access policy determines which mechanism is used to enforce file security on the particular file system.

PowerStore Manager 49
 NOTE: If the older SMB1 protocol needs to be supported in your environment, it can be enabled by using the
svc_nas_cifssupport service command. For more information about this service command, see the PowerStore
Service Scripts Guide.

UNIX security model

When the UNIX policy is selected, any attempt to change file level security from the SMB protocol, such as changes to access
control lists (ACLs), is ignored. UNIX access rights are referred to as the mode bits or NFSv4 ACL of a file system object.
Mode bits are represented by a bit string. Each bit represents an access mode or privilege that is granted to the user owning
the file, the group associated with the file system object, and all other users. UNIX mode bits are represented as three sets of
concatenated rwx (read, write, and execute) triplets for each category of users (user, group, or other). An ACL is a list of users
and groups of users by which access to, and denial of, services is controlled.

Windows security model

The Windows security model is based primarily on object rights, which involve the use of a security descriptor (SD) and its ACL.
When SMB policy is selected, changes to the mode bits from the NFS protocol are ignored.
Access to a file system object is based on whether permissions have been set to Allow or Deny through the use of a security
descriptor. The SD describes the owner of the object and group SIDs for the object along with its ACLs. An ACL is part of the
security descriptor for each object. Each ACL contains access control entries (ACEs). Each ACE in turn, contains a single SID
that identifies a user, group, or computer and a list of rights that are denied or allowed for that SID.

File systems access in a multiprotocol environment

File access is provided through NAS servers. A NAS server contains a set of file systems where data is stored. The NAS server
provides access to this data for NFS and SMB file protocols by sharing file systems through SMB shares and NFS shares.
The NAS server mode for multiprotocol sharing allows the sharing of the same data between SMB and NFS. Because the
multiprotocol sharing mode provides simultaneous SMB and NFS access to a file system, the mapping of Windows users to UNIX
users and defining the security rules to use (mode bits, ACL, and user credentials) must be considered and configured properly
for multiprotocol sharing.
NOTE: For information about configuring and managing NAS servers with regard to multiprotocol sharing, user mapping,
access policies, and user credentials, see the PowerStore Manager online help.

User mapping
In a multiprotocol context, a Windows user needs to be matched to a UNIX user. However, a UNIX user has to be mapped to a
Windows user only when the access policy is Windows. This matching is necessary so that file system security can be enforced,
even if it is not native to the protocol. The following components are involved in user mapping:
● UNIX Directory Services, local files, or both
● Windows resolvers
● Secure mapping (secmap) - a cache that contains all mappings between SIDs, and UID or GIDs used by a NAS server.
● ntxmap
NOTE: User mapping does not affect the users or groups that are local to the SMB server.

UNIX Directory Services and local files

UNIX Directory Services (UDSs) and local files are used to do the following:
● Return the corresponding UNIX account name for a particular user identifier (UID).
● Return the corresponding UID and primary group identifier (GID) for a particular UNIX account name.
The supported services are:
● LDAP
● NIS

50 PowerStore Manager
● Local files
● None (the only possible mapping is through the default user)
There should be one UDS enabled or local files enabled, or both local files and a UDS enabled for the NAS server when
multiprotocol sharing is enabled. The Unix directory service property of the NAS server determines which is used for user
mapping.

Windows resolvers
Windows resolvers are used to do the following for user mapping:
● Return the corresponding Windows account name for a particular security identifier (SID)
● Return the corresponding SID for a particular Windows account name
The Windows resolvers are:
● The domain controller (DC) of the domain
● The local group database (LGDB) of the SMB server

secmap
The function of secmap is to store all SID-to-UID and primary GID and UID-to-SID mappings to ensure coherency across all file
systems of the NAS server.

ntxmap
ntxmap is used to associate a Windows account to a UNIX account when the name is different. For example, if there is a user
who has an account that is called Gerald on Windows but the account on UNIX is called Gerry, ntxmap is used to make the
correlation between the two.

SID to UID, primary GID mapping

The following sequence is the process used to resolve an SID to a UID, primary GID mapping:
1. secmap is searched for the SID. If the SID is found, the UID and GID mapping is resolved.
2. If the SID is not found in secmap, the Windows name related to the SID must be found.
a. The local group databases of the SMB servers of the NAS are searched for the SID. If the SID is found, the related
Windows name is the local user name along with the SMB server name.
b. If the SID is not found in the local group database, the DC of the domain is searched. If the SID is found, the related
Windows name is the user name. If the SID is not resolvable, access is denied.
3. The Windows name is translated into a UNIX name. The ntxmap is used for this purpose.
a. If the Windows name is found in ntxmap, the entry is used as the UNIX name.
b. If the Windows name is not found in ntxmap, the Windows name is used as the UNIX name.
4. The UDS (NIS server, LDAP server, or local files) is searched using the UNIX name.
a. If the UNIX user name is found in the UDS, the UID and GID mapping is resolved.
b. If the UNIX name is not found, but the automatic mapping for unmapped Windows accounts feature is enabled, the UID is
automatically assigned.
c. If the UNIX user name is not found in the UDS but there is a default UNIX account, the UID and GID mapping is resolved
to that of the default UNIX account.
d. If the SID is not resolvable, access is denied.
If the mapping is found, it is added in the persistent secmap database. If the mapping is not found, the failed mapping is added
to the persistent secmap database.
The following diagram illustrates the process used to resolve an SID to a UID, primary GID mapping:

PowerStore Manager 51
 Yes UID and Yes UID and
In In Local Files
SID secmap Primary Primary
secmap? or UDS?
GID GID

No No

In Local Windows Name UID and

Yes Automatic Yes
Group used for SMB-only Primary
Mapping?
Database? access GID

No No

In Windows UID and

Domain Yes Name In Yes UNIX Name Default UNIX Yes
Primary
Controller? ntxmap? Account?
GID

No No No
Windows Name =
UNIX Name
Unknown SID Failed Mapping
Access Denied Access Denied

Figure 2. Process for resolving an SID to a UID, primary GID mapping

UID to SID mapping

The following sequence is the process used to resolve a UID to an SID mapping:
1. secmap is searched for the UID. If the UID is found, the SID mapping is resolved.
2. If the UID is not found in secmap, the UNIX name related to the UID must be found.
a. The UDS (NIS server, LDAP server, or local files) is searched using the UID. If the UID is found, the related UNIX name is
the user name.
b. If the UID is not found in the UDS but there is a default Windows account, the UID is mapped to the SID of the default
Windows account.
3. If the default Windows account information is not used, the UNIX name is translated into a Windows name. The ntxmap is
used for this purpose.
a. If the UNIX name is found in ntxmap, the entry is used as the Windows name.
b. If the UNIX name is not found in ntxmap, the UNIX name is used as the Windows name.
4. The Windows DC or the local group database is searched using the Windows name.
a. If the Windows name is found, the SID mapping is resolved.
b. If the Windows name contains a period, and the part of the name following the last period (.) matches an SMB server
name, the local group database of that SMB server is searched to resolve the SID mapping.
c. If the Windows name is not found but there is a default Windows account, the SID is mapped to that of the default
Windows account.
d. If the SID is not resolvable, access is denied.
If the mapping is found, it is added in the persistent secmap database. If the mapping is not found, the failed mapping is added
to the persistent secmap database.
The following diagram illustrates the process used to resolve a UID to an SID mapping:

52 PowerStore Manager
 In
In Yes Domain Yes
UID secmap SID SID
secmap? Controller?

No No

UNIX Windows
Yes Name Yes Name In Local Yes
In Local Files In
Group SID
or UDS? ntxmap?
Database?
Windows Name =
No UNIX Name No
No

Default Yes
Windows SID
Account?

No

Unresolvable UID
Access Denied

Figure 3. Process used to resolve a UID to an SID mapping

Access policies for NFS, SMB, and FTP

In a multiprotocol environment, the storage system uses file system access policies to manage user access control of its file
systems. There are two kinds of security, UNIX and Windows.
For UNIX security authentication, the credential is built from the UNIX Directory Services (UDS). There is an exception for
nonsecure NFS access, where the host client provides the credential. User rights are determined from the mode bits and NFSv4
ACL. The user and group identifiers (UID and GID, respectively) are used for identification. There are no privileges that are
associated with UNIX security.
For Windows security authentication, the credential is built from the Windows domain controller (DC) and Local Group
Database (LGDB) of the SMB server. User rights are determined from the SMB ACLs. The security identifier (SID) is used
for identification. There are privileges that are associated with Windows security, such as TakeOwnership, Backup, and Restore.
The LGDB or group policy object (GPO) of the SMB server grant these privileges.
The following table describes the access policies that define the security that is used by the different protocols:

Table 9. Access policies that define the security used by NFS and SMB protocols
Access policy Description
Native ● Each protocol manages access with its native security.
(default) ● Security for NFS shares uses the UNIX credential that is associated with the request to check the NFSv3
UNIX mode bits or NFSv4 ACL. The access is then granted or denied.
● Security for SMB shares uses the Windows credential that is associated with the request to check the
SMB ACL. The access is then granted or denied.
● NFSv3 UNIX mode bits and NFSv4 ACL permission changes are synchronized to each other.
● There is no synchronization between the UNIX and Windows permissions.
Windows ● Secures file level access for Windows and UNIX using Windows security.
● Uses a Windows credential to check the SMB ACL.
● An SMB ACL conversion determines the permissions for newly created files. SMB ACL permission changes
are synchronized to the NFSv3 UNIX mode bits or NFSv4 ACL.
● NFSv3 mode bits and NFSv4 ACL permission changes are denied.
UNIX ● Secures file level access for Windows and UNIX using UNIX security.
● Upon request for SMB access, the UNIX credential that is built from the local files or UDS is used to check
the NFSv3 mode bits or NFSv4 ACL for permissions.
● The UMASK determines permissions for newly created files.

PowerStore Manager 53
Table 9. Access policies that define the security used by NFS and SMB protocols (continued)
Access policy Description
● NFSv3 UNIX mode bits or NFSv4 ACL permission changes are synchronized to the SMB ACL.
● SMB ACL permission changes are allowed in order to avoid causing disruption, but these permissions are
not maintained.

For FTP, authentication with Windows or UNIX depends on the username format that is used when authenticating to the NAS
server. If Windows authentication is used, FTP access control is similar to the access control for SMB; otherwise, authentication
is similar to the authentication for NFS. FTP and SFTP clients are authenticated when they connect to the NAS server. It could
be an SMB authentication (when the format of the username is domain\user or user@domain) or a UNIX authentication
(for the other formats of a single username). The Windows DC of the domain that is defined in the NAS server ensures the
SMB authentication. The NAS server according to the encrypted password stored in either a remote LDAP server, a remote NIS
server, or in the local password file of the NAS server ensures the UNIX authentication.

Credentials for file level security

To enforce file-level security, the storage system must build a credential that is associated with the SMB or NFS request being
handled. There are two kinds of credentials, Windows and UNIX. UNIX and Windows credentials are built by the NAS server for
the following use cases:
● To build a UNIX credential with more than 16 groups for an NFS request. The extended credential property of the NAS
server must be set to provide this ability.
● To build a UNIX credential for an SMB request when the access policy for the file system is UNIX.
● To build a Windows credential for an SMB request.
● To build a Windows credential for an NFS request when the access policy for the file system is Windows.
NOTE: For an NFS request when the extended credential property is not set, the UNIX credential from the NFS request is
used. When using Kerberos authentication for an SMB request, the Windows credential of the domain user is included in the
Kerberos ticket of the session setup request.
A persistent credential cache is used for the following:
● Windows credentials built for access to a file system having a Windows access policy.
● Unix credential for access through NFS if the extended credential option is enabled.
There is one cache instance for each NAS server.

Granting access to unmapped users

Multiprotocol requires the following:
● A Windows user must be mapped to a UNIX user.
● A UNIX user must be mapped to a Windows user in order to build the Windows credential when the user is accessing a file
system that has a Windows access policy.
Two properties are associated to the NAS server with regards to unmapped users:
● The default UNIX user.
● The default Windows user.
When an unmapped Windows user attempts to connect to a multiprotocol file system and the default UNIX user account is
configured for the NAS server, the user identifier (UID) and primary group identifier (GID) of the default UNIX user are used
in the Windows credential. Similarly, when an unmapped UNIX user attempts to connect to a multiprotocol file system and the
default Windows user account is configured for the NAS server, the Windows credential of the default Windows user is used.
NOTE: If the default UNIX user is not set in the UNIX Directory Services (UDS), SMB access is denied for unmapped users.
If the default Windows user is not found in the Windows DC or the LGDB, NFS access on a file system that has a Windows
access policy is denied for unmapped users.

NOTE: The default UNIX user can be a valid existing UNIX account name or follow the new format
@uid=xxxx,gid=yyyy@, where xxxx and yyyy are the decimal numerical values of the UID and the primary GID,
respectively, and can be configured on the system through PowerStore Manager.

54 PowerStore Manager
UNIX credential for NFS requests
To handle NFS requests for an NFS only or multi-protocol file system with a UNIX or native access policy, a UNIX credential
must be used. The UNIX credential is always embedded in each request; however, the credential is limited to 16 extra groups.
The NFS server extendedUnixCredEnabled property provides the ability to build a credential with more than 16 groups. If
this property is set, the active UDS is queried with the UID to get the primary GID and all the group GIDs to which it belongs. If
the UID is not found in the UDS, the UNIX credential embedded in the request is used.

NOTE: For NFS secure access, the credential is always built using the UDS.

UNIX credential for SMB requests

To handle SMB requests for a multi-protocol file system with a UNIX access policy, a Windows credential must first be built for
the SMB user at the session setup time. The SID of the Windows user is used to find the name from the AD. That name is then
used (optionally through ntxmap) to find a Unix UID and GID from the UDS or local file (passwd file). The owner UID of the user
is included in the Windows credential. When accessing a file system with a UNIX access policy, the UID of the user is used to
query the UDS to build the UNIX credential, similar to building an extended credential for NFS. The UID is required for quota
management.

Windows credential for SMB requests

To handle SMB requests for an SMB only or a multi-protocol file system with a Windows or native access policy, a Windows
credential must be used. The Windows credential for SMB needs to be built only once at the session setup request time when
the user connects.
When using Kerberos authentication, the credential of the user is included in the Kerberos ticket of the session setup request,
unlike when using NT LAN Manager (NTLM). Other information is queried from the Windows DC or the LGDB. For Kerberos the
list of extra group SIDs is taken from the Kerberos ticket and the list of extra local group SIDs. The list of privileges are taken
from the LGDB. For NTLM the list of extra group SIDs is taken from the Windows DC and the list of extra local group SIDs. The
list of privileges are taken from the LGDB.
Additionally, the corresponding UID and primary GID are also retrieved from the user mapping component. Since the primary
group SID is not used for access checking, the UNIX primary GID is used instead.
NOTE: NTLM is an older suite of proprietary security protocols that provides authentication, integrity, and confidentiality
to users. Kerberos is an open standard protocol that provides faster authentication through the use of a ticketing system.
Kerberos adds greater security than NTLM to systems on a network.

Windows credential for NFS requests

The Windows credential is only built or retrieved when a user through an NFS request attempts to access a file system that has
a Windows access policy. The UID is extracted from the NFS request. There is a global Windows credential cache to help avoid
building the credential on each NFS request with an associated retention time. If the Windows credential is found in this cache,
no other action is required. If the Windows credential is not found, the UDS or local file is queried to find the name for the UID.
The name is then used (optionally, through ntxmap) to find a Windows user, and the credential is retrieved from the Windows
DC or LGDB. If the mapping is not found, the Windows credential of the default Windows user is used instead, or the access is
denied.

Data protection with secure snapshots

Secure snapshots provide protection from accidental or malicious deletion of backup data and are effective against ransom
attacks. Generating secure snapshots guarantees that you can restore data to a previous point in time.
PowerStore version 3.5 or later enable you to generate secure snapshots. Unlike regular snapshots, secure snapshots cannot be
manually deleted and are deleted only when they expire. Also, volumes and clones that have secure snapshots cannot be deleted
until the snapshots expire. The expiration time of secure snapshots cannot be reduced but can be modified to a later date/time.

NOTE: Secure snapshots are only supported for block snapshots created for volume or volume groups.

It is possible to convert existing non-secure snapshots to secure and, similarly, to convert non-secure snapshot rules to secure.

PowerStore Manager 55
Following a PowerStore upgrade to version 3.5, existing snapshots and snapshot rules can be modified to secure.
For detailed information about creating a secure snapshot rule and creating a secure snapshot, see the related PowerStore
Online Help and the PowerStore Protecting Your Data Guide.
If you need to delete a secure snapshot that is not expired, contact Dell Support.

Communication between PowerStore and a Metro

Witness
A PowerStore appliance communicates with the Metro Witness, and the witness responds to the PowerStore appliance. The
witness never initiates communication with a PowerStore appliance.
PowerStore appliances communicate with the witness over HTTPS using port 443 and employing TLS 1.2. The witness uses
a self-signed certificate that is exchanged with the PowerStore appliance to negotiate the secure connection. The key size is
4096 bits and uses the RSA BSafe key algorithm, and the thumbprint algorithm is SHA-256. The witness self-signed certificate
is encrypted and stored on the witness.
Each PowerStore appliance that communicates with the witness provides a Certificate Authority (CA) certificate to validate the
appliance as the client of the secure handshake. The scope field is used to differentiate these CA certificates. Each PowerStore
appliance applies its serial number as the scope. These certificates are also encrypted and stored on the witness.

NOTE: For information about Metro Witness, see PowerStore Protecting Your Data Guide.

Generating a Metro Witness secure token

When configuring Metro Witness on a PowerStore appliance, you must provide the PowerStore appliance with the secure token
of the witness. The secure token expires 10 minutes after it is generated. If the secure token is invalid or expired, you cannot
add the witness to the PowerStore appliance.
PowerStore uses the secure token that is generated on the witness host for authentication. A user with administrator privilege
must log in to the witness host and then use the generate_token.sh script to generate the secure token. The script is
installed in /opt/dell-witness-service/scripts.
The following is an example of using the generate_token.sh script to generate the token:

./generate_token.sh
The generated token is: A1BCDE2a

Retrieving a Metro Witness thumbprint for validation

For an additional layer of security, it is recommended that you validate the thumbprint of the Metro Witness certificate when
you add the witness to a PowerStore appliance.
When the witness software is installed, the thumbprint.sh script is also installed. The script is installed in /opt/dell-
witness-service/scripts. A user with administrator privilege can use the thumbprint.sh script to retrieve the
thumbprint from the certificate of the witness. The following is an example of using the thumbprint.sh script to retrieve the
thumbprint:

./utilities/thumbprint.sh
The certificate thumbprint is:
374dfecc2584799209c370e28d38e0102eae98ef8816237f1a41aeb6848d3a5b

Before adding a witness to the PowerStore appliance, you should retrieve the thumbprint from the witness. Compare that
thumbprint to the thumbprint that appears in the User Authorization slide out panel in PowerStore Manager when adding the
witness. Only click Confirm when the thumbprints match.

56 PowerStore Manager
Port usage
The following sections outline the collection of network ports and the corresponding services that may be found on the
appliance. The appliance functions as a network client in several circumstances, for example, in communicating with a vCenter
Server. In these instances, the appliance initiates communication and the network infrastructure will need to support these
connections.
NOTE: For additional information about ports, see KB article 000022861, PowerStore: User Network Firewall Rules Tool
- TCP/UDP Ports. The tool enables you to filter and review the list of firewall rules and ports that are relevant to your
PowerStore deployment.

Appliance network ports

The following table outlines the collection of network ports and the corresponding services that may be found on the appliance.

Table 10. Appliance network ports

Port Service Protocol Access Direction Description
22 SSH client TCP Inbound Used for SSH access (if enabled). If
closed, management connections using
SSH is not available.
25 or 587 SMTP TCP Outbound Used by the appliance to send email. If
closed, email notifications cannot be sent.
26 SSH client TCP Bi-directional SSH access to port 22 is redirected
to this port. If closed, management
connections using SSH are not available.
53 DNS TCP or UDP Outbound Used to transmit DNS queries to the DNS
server. If closed, DNS name resolution
does not work.
80, 8080, 3128 Support TCP Outbound Used for Support Connectivity Proxy
Connectivity connection.
111 PortMapper TCP or UDP Bi-directional Used to assign a random port for the
mountd service that is used by DD Boost
and NFS.
123 NTP TCP or UDP Outbound NTP time synchronization. If closed, time
is not synchronized among appliances.
162 or between SNMP UDP Outbound SNMP communications. If closed, storage
1024–49151 system alert mechanisms which rely on
SNMP are not sent. The default port set
for SNMP is 162.
443 HTTPS, block TCP Bi-directional Secure HTTP traffic to PowerStore
replication, remote Manager. Also used for block replication
backup management communication between
clusters and remote backup management
communication between PowerStore and
PowerProtect Data Domain. If closed,
communication with the appliance is not
available.
500 IPsec (IKEv2) UDP Bi-directional To make IPSec work through your
firewalls, open UDP port 500 and permit
IP protocol numbers 50 and 51 on both
inbound and outbound firewall filters.
UDP Port 500 should be opened to
allow Internet Security Association and
Key Management Protocol (ISAKMP)
traffic to be forwarded through your

PowerStore Manager 57
Table 10. Appliance network ports (continued)
Port Service Protocol Access Direction Description
firewalls. IP protocol ID 50 should be
set to allow IPSec Encapsulating Security
Protocol (ESP) traffic to be forwarded.
IP protocol ID 51 should be set to allow
Authentication Header (AH) traffic to be
forwarded. If closed, IPsec connection
between PowerStore appliances is not
available.
514 Remote Logging UDP Outbound Used by the appliance to send log
messages to remote syslog servers. If
closed, log messages cannot be sent to
remote syslog servers.
1468 Remote Logging TCP Outbound Used by the appliance to send log
messages to remote syslog servers. If
closed, log messages cannot be sent to
remote syslog servers.
2049 DDBoost/NFS TCP Bi-directional Main port used by NFS.
2051 DDBoost TCP Bi-directional Used only if replication is configured.
2052 DDBoost/NFS TCP Bi-directional Used by the DDboost protocol.
3033 Import TCP or UDP Outbound Required for storage import from legacy
EqualLogic Peer Storage and Dell
Compellent Storage Center systems.
3260 iSCSI TCP ● Inbound for Required to provide the following access
Host and ESXi to iSCSI services:
host access ● External host iSCSI access
● Bi-directional for ● External or PowerStore embedded
replication ESXi host iSCSI access
● Outbound ● Inter-cluster access for replication
storage for ● Storage import access from legacy
import EqualLogic Peer Storage, Dell
Compellent Storage Center, Unity, and
VNX2 systems
If closed, iSCSI services are not available.
Used by Data mobility to support
reasonable replication performance on
low-latency connection.
3261 Data mobility TCP Bi-directional Used by Data mobility to support
reasonable replication performance on
high latency connection.
4420 I/O Controller TCP ● Inbound for Required to provide the following access
Host and ESXi to NVMe/TCP I/O Controller services:
host access ● External host NVMe/TCP access
● Bi-directional for ● External or PowerStore embedded
replication ESXi host NVMe/TCP access
● Outbound for ● Inter-cluster access for replication
storage import ● Storage import access from legacy
EqualLogic Peer Storage, Dell
Compellent Storage Center, Unity, and
VNX2 systems
If closed, NVMe TCP I/O I/O Controller
services are not available.
5353 Multicast DNS UDP Bi-directional Multicast DNS query. If closed, mDNS
(mDNS) name resolution does not work.

58 PowerStore Manager
Table 10. Appliance network ports (continued)
Port Service Protocol Access Direction Description
5555 RSA SecurID TCP Outbound Used to communicate with an RSA
Authentication Authentication server when the RSA
SecurID Authentication feature is enabled.
If closed, authentication using the RSA
SecurID Authentication server does not
function. The default port set for RSA
SecurID Authentication is 5555.
8009 Discovery TCP Bi-directional Used by Data mobility to support
Controller reasonable replication performance on
high latency connection. If closed, NVMe
TCP Discovery services are unavailable.
8443 VASA Support TCP ● Inbound for ● Required for the VASA Vendor
Connectivity VASA Provider for VASA 3.0.
● Outbound for ● Required for the related Support
Support Connectivity Connect Home
Connectivity functions.
8443, 50443, Windows import TCP Outbound One of these ports must be open
55443, or 60443 host agent, Linux when importing data storage from legacy
import host agent, storage systems.
or VMware import
host agent
9443 Support TCP Outbound Required for Support Connectivity REST
Connectivity API related to Connect Home.
13333 Data mobility TCP Bi-directional Used by iBasic replication data traffic on
block replication network interfaces for
latency setting: Low
13334 Data mobility TCP Bi-directional Used by iBasic replication data traffic on
block replication network interfaces for
latency setting: Low_Medium
13335 Data mobility TCP Bi-directional Used by iBasic replication data traffic on
block replication network interfaces for
latency setting: Medium
13336 Data mobility TCP Bi-directional Used by iBasic replication data traffic on
block replication network interfaces for
latency setting: Medium_High
13337 Data mobility TCP Bi-directional Used by iBasic replication data traffic on
block replication network interfaces for
latency setting: High

Appliance network ports related to file

The following table outlines the collection of network ports and the corresponding services that may be found on the appliance
that is related to file.

NOTE: Outbound ports are ephemeral.

Table 11. Appliance network ports related to file

Port Service Protocol Access Direction Description
20 FTP TCP Outbound Port used for FTP data transfers. This
port can be opened by enabling FTP.
Authentication is performed on port 21
and defined by the FTP protocol.

PowerStore Manager 59
Table 11. Appliance network ports related to file (continued)
Port Service Protocol Access Direction Description
21 FTP TCP Inbound Port 21 is the control port on which
the FTP service listens for incoming FTP
requests.
22 SFTP TCP Inbound Allows alert notifications through SFTP
(FTP over SSH). SFTP is a client/server
protocol. Users can use SFTP to perform
file transfers on an appliance on the local
subnet. Also, it provides an outgoing FTP
control connection. If closed, FTP is not
available.
53 DNS TCP or UDP Outbound Used to transmit DNS queries to the DNS
server. If closed, DNS name resolution
does not work. Required for SMB v1.
88 Kerberos TCP or UDP Outbound Required for Kerberos authentication
services.
111 RPC bind (for TCP or UDP Bi-directional Opened by the standard portmapper
file services or rpcbind service and is an ancillary
namespaces; appliance network service. It cannot be
otherwise, host stopped. By definition, if a client system
service) has network connectivity to the port,
it can query it. No authentication is
performed.
123 NTP UDP Outbound NTP time synchronization. If closed, time
is not synchronized among appliances.
135 Microsoft RPC TCP Inbound Multiple purposes for Microsoft Client.
137 Microsoft Netbios UDP; TCP or Inbound; Outbound The NetBIOS Name Service is associated
WINS UDP with the appliance SMB file sharing
services and is a core component of
that feature (Wins). If disabled, this port
disables all SMB-related services.
138 Microsoft Netbios UDP Outbound The NetBIOS Datagram Service is
BROWSE associated with the appliance SMB file
sharing services and is a core component
of that feature. Only the Browse service
is used. If disabled, this port disables
Browsing capability.
139 Microsoft SMB TCP Bi-directional The NetBIOS Session Service is
associated with appliance SMB file
sharing services and is a core component
of that functionality. If SMB services are
enabled, this port is open. It is required
for SMB v1.
162 or between SNMP UDP Outbound SNMP communications. If closed, storage
1024-49151 system alert mechanisms which rely on
SNMP are not sent. The default port set
for SNMP is 162.
389 LDAP TCP or UDP Outbound Unsecure LDAP queries. If closed,
Unsecure LDAP authentication queries are
not available. Secure LDAP is configurable
as an alternative.
445 Microsoft SMB TCP Inbound SMB (on domain controller) and SMB
connectivity port for Windows 2000
and later clients. Clients with legitimate

60 PowerStore Manager
Table 11. Appliance network ports related to file (continued)
Port Service Protocol Access Direction Description
access to the appliance SMB services
must have network connectivity to the
port for continued operation. Disabling
this port disables all SMB-related
services. If port 139 is also disabled, SMB
file sharing is disabled.
464 Kerberos TCP or UDP Outbound Required for Kerberos authentication
services and SMB.
500 IPsec (IKEv2) UDP Bi-directional To make IPSec work through your
firewalls, open UDP port 500 and permit
IP protocol numbers 50 and 51 on both
inbound and outbound firewall filters.
UDP Port 500 should be opened to
allow Internet Security Association and
Key Management Protocol (ISAKMP)
traffic to be forwarded through your
firewalls. IP protocol ID 50 should be
set to allow IPSec Encapsulating Security
Protocol (ESP) traffic to be forwarded.
IP protocol ID 51 should be set to allow
Authentication Header (AH) traffic to be
forwarded. If closed, IPsec connection
between PowerStore appliances is not
available.
514 Remote Logging UDP Outbound Allows the appliance to send log
messages to remote syslog servers. If
closed, log messages cannot be sent to
remote syslog servers.
636 LDAPS TCP or UDP Outbound Secure LDAP queries. If closed, secure
LDAP authentication is not available.
1234 NFS mountd TCP or UDP Bi-directional Used for the mount service, which is
a core component of the NFS service
(versions 2, 3, and 4).
1468 Remote Logging TCP Outbound Allows the appliance to send log
messages to remote syslog servers. If
closed, log messages cannot be sent to
remote syslog servers.
2000 SSHD TCP Inbound SSHD for serviceability (optional)
2049 NFS I/O TCP or UDP Bi-directional Used to provide NFS services.
3268 LDAP UDP Outbound Unsecure LDAP queries. If closed,
Unsecure LDAP authentication queries are
not available.
3269 LDAPS UDP Outbound Secure LDAP queries. If closed, Secure
LDAP authentication queries are not
available.
4000 STATD for NFSv3 TCP or UDP Bi-directional Used to provide NFS statd services. statd
is the NFS file-locking status monitor and
works with lockd to provide crash and
recovery functions for NFS. If closed,
NAS statd services are not available.
4001 NLMD for NFSv3 TCP or UDP Bi-directional Used to provide NFS lockd services.
lockd is the NFS file-locking daemon.
It processes lock requests from NFS

PowerStore Manager 61
Table 11. Appliance network ports related to file (continued)
Port Service Protocol Access Direction Description
clients and works with the statd daemon.
If closed, NAS lockd services are not
available.
4002 RQUOTAD for TCP or UDP; Inbound; Outbound Used to provide NFS rquotad services.
NFSv3 UDP The rquotad daemon provides quota
information to NFS clients that have
mounted a file system. If closed, NAS
rquotad services are not available.
4003 XATTRPD TCP or UDP Inbound Required for managing file attributes in a
(extended file multi-protocol environment.
attribute)
4658 PAX (NAS server TCP Inbound PAX is an appliance archive protocol that
archive) works with standard UNIX tape formats.
5085, 5086 File replication TCP Bi-directional Used by management communication
(replication for file services file replication between
management clusters.
traffic)
8888 File replication TCP Bi-directional Used between replication network IP
(replication data addresses on the file services file
traffic) replication network interfaces.
10000 NDMP TCP Inbound ● Enables you to control the backup
and recovery of a Network Data
Management Protocol (NDMP) server
through a network backup application,
without installing third party software
on the server. In an appliance, the
NAS Server functions as the NDMP
server.
● If NDMP tape backup is not used, the
NDMP service can be disabled.
● The NDMP service is authenticated
with a username and password pair.
The username is configurable. The
NDMP documentation describes how
to configure the password for various
environments.
[10500,10531] NDMP reserved TCP Inbound For three-way backup/restore sessions,
range for NDMP NAS Servers use ports 10500–10531.
dynamic ports
12228 Antivirus checker TCP Outbound Required for the Antivirus checker
service service.

HTTP redirect to HTTPS

HTTP is not supported for security purposes. Enabling the HTTP redirect to HTTPS feature allows users that go to PowerStore
Manager to be automatically redirected from http: to https://. However, enabling HTTP redirect is less secure than having
users type the full https:// address at the time of PowerStore Manager login. The HTTP redirect feature is disabled by
default.
Enabling or disabling the HTTP redirect to HTTPS feature is a cluster-wide operation.

62 PowerStore Manager
Configuring HTTP Redirect to HTTPS
Configure HTTP redirect to HTTPS for a PowerStore cluster through any of the following means:
● Initial Configuration – A wizard used to initially configure the PowerStore appliance (select the Enable HTTP redirect to
HTTPS for Cluster IP checkbox on the Management Network page).
● HTTP Redirect - An HTTP Redirect settings page that you can access from the PowerStore Manager (click Settings and,
under Security, select HTTP Redirect).
● REST API server - Application interface that can receive REST API requests to configure the HTTP redirect setting. For
more information about the REST API, see the PowerStore REST API Reference Guide.
Use any of these methods to enable or disable HTTP redirect to HTTPS. To determine the status of the feature in PowerStore
Manager, click Settings and, under Security, select HTTP Redirect.

Auditing
Auditing provides a historical view of users activity on the system. A user with the role of Administrator, Security Administrator,
or Storage Administrator can use the REST API to search for and view configuration change events on the system. These
events that are audited are not just security related, all set operations (that is, POST/PATCH/DELETE) are audit logged.
Other interfaces such as the PowerStore Manager UI and the CLI can be used to search and view audit events.

Remote logging
The storage system supports sending audit log messages and system alert-related events to a maximum of two hosts. The hosts
must be accessible from the storage system. Audit log message and system alert-related event transfers can use a one-way
authentication (Server CA Certificates) or an optional two-way authentication (Mutual Authentication Certificate). An imported
certificate applies to each remote syslog server that is configured to use TLS Encryption.
To review or update remote logging settings, log in to PowerStore Manager and click Settings, and under Security select
Remote Logging.
The following information appears on the Remote Logging page for Remote Syslog Servers:
● Disabled or Enabled - Status of the sending log information to a remote host.
● Host IP address - Where the storage system sends remote log information.
● Port number and protocol (UDP or TCP) - The storage system transfers audit log information through port 514 using the
UDP protocol or port 1468 using the TCP protocol.
● Use certificate - A Server CA Certificate for one-way authentication with your remote syslog server is required to be
imported for remote syslog servers that are configured to use TLS Encryption.
● Audit Types - Types of audit events to send to the remote syslog server. The following types of audit events can be selected
to be sent to the remote syslog server:
○ Authentication
○ Authorization
○ Config (Configuration)
○ Logout
○ System
○ Service
● Send Alerts - Send system alert-related events to the remote syslog server.
NOTE: For each server that is configured to receive alerts, any newly-generated event associated with an alert in the
system will be forwarded to the server.
The following information appears on the Remote Logging page for certificates:
● Service - Remote Logging
● Type - Server CA Certificate or Mutual Authentication Certificate
● Scope - Remote Logging
● Issued by - Authority issuing the certificate
● Valid - Indicates whether the certificate is valid for use
● Valid to - Expiry date of the certificate
● Issued to - Entity receiving the certificate

PowerStore Manager 63
Configuring a remote syslog server to receive storage system log
messages
Before configuring remote logging for a storage system, you must configure each remote system to receive logging messages
from the storage system. A root or administrator on the receiving system can configure the remote syslog server or rsyslog
server to receive log information by editing the syslog server or rsyslog server configuration file (syslogng.conf or rsyslog.conf)
on the remote system.
NOTE: For more information about setting up and running a remote syslog server, see the documentation for the operating
system running on the remote system.

Add Remote Syslog Server

Prerequisites
Before adding a remote syslog server, ensure that you have obtained the following remote syslog server details:
● Host/IP address
● Protocol to use
● Whether TLS encryption is used
● Audit types to send
● Whether to send system alert-related events
If log message and system alert-related event transfers use TLS encryption and a Server Certificate Authority (CA) Certificate
has not been imported, import the Server CA Certificate to PowerStore. The Server CA Certificate is required for TLS
encryption.
Only two-way authentication is supported. If a signed Mutual Authentication Certificate (Client CA Certificate) has not been
imported, import the signed Mutual Authentication Certificate to PowerStore.
NOTE: To acquire a signed Mutual Authentication Certificate for import, a Certificate Signing Request (CSR) must be
generated for it and signed by your certificate authority before it can be imported to PowerStore.

About this task

To add a Remote Syslog Server using the PowerStore Manager, do the following:

Steps
1. Click Settings and select Remote Logging under Security.
The Remote Logging page appears.
2. Under Remote Syslog Servers, select Add.
The Add Remote Syslog Servers slide out appears.
3. If not enabled, select Enable remote logging.
4. Type in the host IP address of the syslog server.
5. Select the Protocol Type and Port.
NOTE: The corresponding default port for UDP is 514. The corresponding default port for TCP is 1468.

6. If TLS encryption will be used, select Use certificate (TLS encryption).

NOTE: TLS encryption is only allowed with the TCP protocol and when a valid signed server certificate has already been
imported.

7. Under Audit Event Types, select the events that should be sent to the syslog server.
8. If system alert-related events should be sent to the syslog server, select Send Alerts.
9. Click Add.
The syslog server is added to the list of servers under Remote Syslog Servers.
10. (Optional) Select Send Test Message to verify the connection between PowerStore and the remote syslog server.
The Send Test Message slide out appears.
11. (Optional) Type your test message in the Message box.

64 PowerStore Manager
12. (Optional) Click Send.
The Send Test Message slide out closes.

Import a certificate for remote logging

Prerequisites
Before importing a certificate, ensure that you know the location of the certificate file or have the certificate text available to
copy and paste for import.

NOTE: For more information see Format of a certificate or certificate chain before importing it.

About this task

To import a certificate using the PowerStore Manager, do the following:

Steps
1. Click Settings and under Security select Remote Logging.
The Remote logging page appears.
2. Under Certificates, select Import and select the type of certificate to import.
The slide out for the respective certificate appears.
3. Do one of the following:
● Select Select Certificate File, then locate and select the file to import.
● Select Paste Certificate File, then copy and paste the certificate text in the text box.
4. Select Import.
The certificate should appear in the list under Certificates.

Generate a Certificate Signing Request

Prerequisites
Before you generate a Certificate Signing Request (CSR), ensure that you have obtained the following information for the
request:
● Common Name
● IP address
● DNS Name
● Organization
● Organization Unit
● Locality
● State
● Country
● Key Length
● (Optional) Passphrase

About this task

Generating a CSR is applicable to a Mutual Authentication Certificate, which is used in two-way authentication between
PowerStore and the remote syslog server. To generate a CSR using the PowerStore Manager, do the following:

Steps
1. Select Settings and under Security select Remote Logging.
The Remote logging page appears.
2. Select Generate CSR.
The Generate CSR slide out appears.
3. Type in the information that is used to generate the CSR.
4. Click Generate.
The Generate CSR slide out changes to show the next steps that must be taken along with the certificate text.

PowerStore Manager 65
5. Click Copy to clipboard to copy the certificate text to your clipboard.
6. Click Close.
7. Have the certificate signed by the certificate authority (CA) so that it can be imported as a Mutual Authentication
Certificate.

Manage remote logging settings

About this task
You can change the configuration settings of the remote syslog servers, delete remote syslog servers, and send a test message
to a remote syslog server. You can also import either a Server CA Certificate for one-way authentication or an optional Mutual
Authentication Certificate for two-way authentication, delete a certificate, and generate a Certificate Signing Request (CSR).

Steps
1. In PowerStore Manager, select Settings and, under Security, select Remote Logging.
The Remote Logging page appears and lists information about remote syslog servers and associated certificates for
authentication.
2. To modify the configuration settings of a remote syslog server, select the checkbox next to the hostname or IP address of
the remote syslog server and click:

Option Description
Modify The Modify Remote Syslog Server slide-out appears. Change the remote syslog server settings as
needed and click Apply.
NOTE: Using TLS Encryption requires a Server CA Certificate to be imported.

Delete To delete the remote syslog server.

NOTE: To delete multiple remote syslog servers at one time, click the checkbox next to the hostname
or IP address of each remote syslog server to be deleted, then click Delete.

Send Test To send a test message to verify the connection between the PowerStore cluster and the remote syslog
Message server. Sending a test message can only be performed on a single remote syslog server.
3. For certificates, click:

Option Description
Import Select whether to import a Server CA Certificate for one-way authentication or an optional Mutual
Authentication Certificate for two-way authentication. Depending on the type of certificate selected to
import, either the Import Server CA Certificate or Import Mutual Authentication Certificate slide-out
appears.
NOTE: For either type of certificate, you have the options either to select a certificate file to import or
copy and paste the certificate text to import. A certificate that is imported applies to each remote syslog
server that is configured to use TLS Encryption.

CAUTION: Importing a new CA Certificate will replace the existing certificate that is used by
the PowerStore cluster.

Delete To delete a selected certificate.

NOTE: Deleting the Server CA Certificate prevents enabling TLS Encryption between the PowerStore
cluster and your remote syslog server.

Generate The Generate CSR slide-out appears. Provide the information that is needed for generating a CSR. Once
CSR the CSR is generated and appears in the slide-out, copy the certificate text to your clipboard, then have the
certificate signed by the certificate authority (CA). Import the signed certificate to PowerStore. A CSR can
be signed by your CA and imported into PowerStore as a Mutual Authentication Certificate.

66 PowerStore Manager
Operational description of Support Connectivity
The following features are available with a warranty or ProSupport Enterprise Suite coverage:

NOTE: Secure Remote Services and SupportAssist Enterprise capabilities are now part of secure connect gateway.

● Proactive, automated issue detection, case creation and notification

● Accelerated issue resolution with remote support and secure, two-way communication between your service provider and
your storage environment
● Analytics-based recommendations for support and services
NOTE: It is strongly recommended that you enable Support Connectivity to accelerate problem diagnosis, perform
troubleshooting, and help speed time to resolution. If you do not enable Support Connectivity, you may need to collect
appliance information manually to assist your service provider with troubleshooting and resolving problems with your
appliance. Also, Support Connectivity must be enabled on the appliance for data to be sent to CloudIQ and to enable use of
the Cybersecurity application.

Support Connectivity enablement precheck

With PowerStore operating system version 4.0 or later versions, Support Connectivity runs a precheck as part of its enablement
process. The precheck proactively confirms whether it is ready to be enabled. This precheck feature identifies common
misconfigurations. The precheck determines the following:
● The DNS configuration on the appliance can properly resolve required hostnames.
● For Connect directly, the required network ports are open so that the appliance can contact the backend servers.
● For Connect via Secure Connect Gateway, the required network ports are open for the appliance to contact the backend
servers.
● The appliance can copy and store valid certificates from the Dell backend servers or Secure Connect Gateway servers to
establish an SSL connection.
● The appliance has sufficient available space and is not running an instance of Support Connectivity.
● The appliance has the required credentials that are installed to enable a successful connection.
● When adding an appliance to a cluster with Support Connectivity enabled, the precheck runs on the new appliance to verify
that the new appliance can enable Support Connectivity as well.
● When modifying the existing Support Connectivity configuration, a subset of the defined tests are run to verify that the new
configuration will be successful.
If the precheck determines that enabling Support Connectivity will fail, it remains disabled. Also, notifications are provided along
with actionable steps to take to remedy issues that are discovered during the precheck.
The Support Connectivity precheck is implemented as a profile within the system health checks. The System Checks tab on
the Monitoring page in PowerStore Manager has an added label and value pair that show the profile of the last system check
results based on the respective profile. Run System Check only triggers the Service Engagement profile. However, other
profiles can be triggered by other operations or actions within PowerStore Manager. For example, when a user enables Support
Connectivity from PowerStore Manager from the Settings page or through the Initial Configuration Wizard (ICW), the System
Checks tab on the Monitoring page shows the results of the system check. The profile reflects Support Connectivity.
When Run System Check is selected, the values for Profile and Last Run change and reflect that a system check is running.
Once the results are available, both values are updated to reflect the Service Engagement profile, and the last run value. The
Job Details for PowerStore Manager reflect the output of the invoked system check. If there were failures during the check,
they are shown in the output of the Job Details.
NOTE: The precheck can also be invoked from the svc_health_check service script. Also, the remote_support
REST API includes a precheck_override option that allows users to skip the Support Connectivity precheck.

Support Connectivity and security

Support Connectivity employs multiple security layers throughout each step in the remote connectivity process to ensure that
you and your service provider can use the solution with confidence:
● All notifications sent to your service provider originate from your site – never from an outside source – and are kept secure
through the use of Advanced Encryption Standard (AES)-256 bit encryption.
● IP-based architecture integrates with your existing infrastructure and maintains the security of your environment.

PowerStore Manager 67
● Communications between your site and your service provider are bilaterally authenticated using digital certificates.
● Supports TLS 1.2
● Only authorized service providers verified through two-factor authentication can download the digital certificates needed to
view a notification from your site.

Support Connectivity management

You can manage Support Connectivity using the PowerStore Manager or the REST API. You can enable or disable the service
and provide the relevant information necessary for the Support Connectivity options you select.

Support Connectivity communication

Support Connectivity cannot be enabled on PowerStore models configured with IPv6 for the management network. Support
Connectivity is not supported over IPv6. Also, management network reconfiguration from IPv4 to IPv6 is not allowed when
Support Connectivity is configured on a cluster.

NOTE: Access to a DNS server is required for Support Connectivity to work.

The connection status of Support Connectivity indicates both the state of the connection between PowerStore and your
service provider's backend Support services and the quality of service of the connection. The connection state is determined
over five minute periods and the quality of service of the connection is determined over 24 hour periods. The connection status
can appear as one of the following based on any of the appliances in the cluster:
● Unavailable – Connectivity data is unavailable. You may have lost contact with an appliance or Support Connectivity has
just been enabled and there is insufficient data to determine the state.
● Disabled – Support Connectivity has not been enabled.
● Not connected – Connectivity has been lost. Five consecutive keepalive failures have been detected.
● Reconnecting – PowerStore is attempting to reconnect after loss of connectivity. Five consecutive successful keepalive
requests are needed to transition back to a connected status.
The connection status can appear as one of the following based on the average of all the appliances in the cluster when
PowerStore is connected to your service provider backend Support services:
● Evaluating – The quality of service for the connection will be undetermined for the first 10 minutes after Support
Connectivity is first initialized.
● Good – 80% or more of the consecutive keepalive requests were successful.
● Fair – Between 50% and 80% of the consecutive keepalive requests were successful.
● Poor – Less than 50% of the consecutive keepalive requests were successful.

Support Connectivity remote support

Support Connectivity and its remote support feature are disabled by default. As part of enabling Support Connectivity and to
use its remote support services, you must accept the End User License Agreement (EULA). Otherwise, Support Connectivity
cannot be enabled and its remote support feature cannot be used. Once the Support Connectivity EULA is accepted, Support
Connectivity and its remote support feature can be configured.
Enabling the remote support feature allows support engineers who are authorized by your service provider to securely access
and troubleshoot your system. This feature allows your service provider's support personnel to remotely log in to the system
to address issues that may occur. Support personnel can remotely log in to your system through SSH or PowerStore Manager.
Your support contract determines what and when support personnel are allowed to do. By enabling this feature, you grant
access to your system so that troubleshooting and fixing issues can happen as they occur. For example, if a call home, data
unavailable or loss, or any otherwise abnormal event occurs, this feature allows your service provider's support personnel to
respond faster to correct issues.

Support Connectivity options

The Support Connectivity options that are available by which to send appliance information to your service provider for remote
troubleshooting are:

68 PowerStore Manager
● Connect via Secure Connect Gateway—This option is for centralized Support Connectivity where secure connect
gateway software runs on a customer-supplied gateway server with two-way file transfer, which includes:
○ Call-homes
○ CloudIQ and Cybersecurity support
○ Software notifications
○ Operating environment and firmware download from your service provider to the cluster
It also includes remote access for the support personnel of your service provider. The gateway server is the single point of
entry and exit for all IP-based Support activities for the appliances that are associated with the gateway.
● Connect Directly—This option is for distributed Support Connectivity where secure connect gateway software runs on
individual appliances with the same two-way file transfer as connecting through a gateway server.
Another option, Disabled, is available but not recommended. If you select this option, your service provider will not receive
notifications about issues with the appliance. You may need to collect appliance information manually to assist support
representatives with troubleshooting and resolving problems with the appliance.

Support Connectivity using the Secure Connect Gateway option

When you select the Connect via Secure Connect Gateway option, your appliance is added to other appliances in a secure
connect gateway cluster. The cluster resides behind a single common (centralized) secure connection between your service
provider's servers and an off-array gateway server. The gateway server is the single point of entry and exit for all IP-based
support activities for the appliances associated with the gateway.
The gateway server is a remote support solution application that is installed on one or more customer-supplied dedicated
servers. The Connect via Secure Connect Gateway option supports up to two gateway servers, one as primary and one as a
backup. The gateway server functions as a communication broker between the associated appliances and your service provider.
To configure your appliance to use the Connect via Secure Connect Gateway option for Support Connectivity, you need to
provide the IP address for each gateway server. Port number 9443 is the default and cannot be changed. Also, ensure that the
port is open between the gateway server and the appliance.
NOTE: The gateway server must be up and running before you configure your appliance to use it. Appliances can only be
added to the gateway from the PowerStore Manager. If the appliance is added from the gateway server, it will appear to be
connected, but will not successfully send system information.

Requirements for Support Connectivity using the Secure Connect

Gateway
The following requirements are applicable to the Connect via Secure Connect Gateway Support Connectivity implementation:
● Network traffic (HTTPS) must be permitted on port 9443 between the appliance and the secure connect gateway server.
Allow access to ports 22, 443, and 8443 between PowerStore and the secure connect gateway server for PowerStore
Manager and SSH accessing. Also, set a reject rule between the appliance and outbound access for ports 443 and 8443 to
ensure that the PowerStore appliance directs traffic to the secure connect gateway server.
● The secure connect gateway server must be version 5.00.06.xy or later.
● Ensure that the PowerStore cluster is running PowerStore operating system version 3.0 or later.
NOTE: Never manually add or remove an appliance from the gateway server. Only add or remove an appliance from the
PowerStore Manager.

Support Connectivity using the Connect Directly option

For the Connect Directly option, secure connect gateway software runs directly on each appliance. In a cluster, each appliance
establishes its own connection to your service provider. Traffic is not routed through the primary appliance in a cluster.
However, Support Connectivity can only be managed at the cluster level, that is, all changes are applied to every appliance in
the cluster.
Enable and configure the Connect Directly option from the Support Connectivity page, which can be accessed through
Settings and is listed under Support in the PowerStore Manager. These actions set up the appliance to use a secure
connection between itself and your service provider.
When you select the Connect Directly option and accept the End User License Agreement (EULA), the appliance sets up a
secure connection between itself and your service provider. This option enables remote access service connectivity capability

PowerStore Manager 69
with the appliance to and from your service provider along with two-way file transfer. If applicable, you can configure the
connection from the appliance to an associated proxy server (optional).
When a new appliance is added to an existing cluster, the new appliance will detect the cluster Support Connectivity
settings and automatically configure the new appliance to match. If the Connect Directly option is currently enabled, it will
be automatically enabled on the new appliance. Additional actions are not necessary. If Connect Directly option cannot be
enabled, it will not prevent the add-appliance process from completing.

Requirements for Support Connectivity using Connect Directly

The following requirement is applicable to the Connect Directly Support Connectivity implementation:
● Network traffic (HTTPS) must be permitted on ports 443 and 8443 (outbound) to your support provider. Failure to open
port 8443 results in significant performance impact (30–45 percent). Failure to open both ports may result in a delay in
resolving issues with the end device. Also, if the connection uses a Proxy server, port 3128 is the default used when the
port is not specified and Support Connectivity is enabled with Connect Directly and a firewall is employed between the
storage system and the Proxy server. If the default or user-specified port is closed, communication with the storage system
through the port will be unavailable.

Configuring Support Connectivity

Configure Support Connectivity for an appliance by using any of the following means:
● Initial Configuration wizard – A user interface that walks you through the initial setup of PowerStore Manager and prepares
the system for use.
● Support Connectivity – A settings page that you can access from the PowerStore Manager (click Settings and under
Support select Support Connectivity).
● REST API server – Application interface that can receive REST API requests to configure Support Connectivity settings. For
more information about the REST API, see the PowerStore REST API Reference Guide.
To determine the status of Support Connectivity, click Settings and under Support select Support Connectivity in the
PowerStore Manager.

Configure the initial setup of Support Connectivity

Prerequisites
To enable Support Connectivity for either the Connect Directly or Connect via Secure Connect Gateway option,
unrestricted access to Dell Support (esrs3-core.emc.com and esrs3-coredr.emc.com) over the Internet using HTTPS (for
nonproxy environments) is required.
When configuring Support Connectivity, if your firewall is configured to inspect TLS certificates for verification, the associated
Certificate Authority certificate files must be added to the list of trusted authorities included in your firewall. The following
required certificate files can be downloaded from their respective link:
● Download the DellSecureRemoteServicesRootCA.crt certificate file from Dell.
● Download the ESRS2CA.cer certificate file from Dell.

About this task

NOTE: Do not use this procedure if the feature has been initially configured and the associated End User License
Agreement (EULA) has been accepted.
Use PowerStore Manager to configure the initial setup of Support Connectivity by doing the following:
NOTE: With PowerStore operating system 2.1 and later releases, this feature cannot be enabled unless the Primary
Contact information with the required values is provided under Support Contacts. Also, after a successful non-disruptive
upgrade, you must either refresh or close and reopen your browser tab to see and use the new functionality; otherwise, you
will still see and use the older functionality.

Steps
1. Click Settings and under Support select Support Connectivity.

70 PowerStore Manager
 The Support Connectivity page appears with Support Contacts selected.
2. Type in the required information.
NOTE: The First Name and Last Name of the Primary Contact are mandatory, and the Email or Phone (at least
one is required) of the Primary Contact. Providing information for the Secondary Contact is optional. Your Support
Connectivity contact information is critical for a quick response to support issues and must be accurate and current.
Also, you can view the Privacy Policy and the Telemetry Notice by selecting the related link in the Support Contacts
introductory text.

3. Click Apply to save the information.

NOTE: You must click Apply before you can navigate from Support Contacts and select Connection Type;
otherwise, a prompt appears asking whether to cancel the navigation move or to discard the information that you
typed in.

4. Select Connection Type.

NOTE: When the initial setup of Support Connectivity has not been configured, the status is shown as Disabled.

5. Click the Enabled/Disabled control to begin enabling Support Connectivity.

NOTE: With PowerStore operating system version 4.0 or later versions, Support Connectivity runs a precheck as part
of its enablement process to proactively confirm that it is ready to be enabled. If the precheck determines that enabling
Support Connectivity will fail, it remains disabled. Also, notifications are provided along with actionable steps to take
to remedy issues that are discovered during the precheck. See Support Connectivity enablement precheck for more
information about the Support Connectivity precheck.

The End User License Agreement (EULA) appears.

6. Click Accept to accept the EULA and enable Support Connectivity.
Support Connectivity can be disabled, however, it is not recommended. Also, if the EULA is not accepted, Support
Connectivity cannot be enabled.
The Enabled/Disabled control should move to the right and change its indication to Enabled. However, the connection
status will not change until after you enter the necessary configuration information and click Apply.
7. Select the Type of Support Connectivity option that you intend to use from the list.
8. Depending on which type of Support Connectivity option you select, do one of the following:
● For the Connect via Secure Connect Gateway option:
○ Specify the IP address of each gateway server, the primary server and, if available, the backup server.
NOTE: Each gateway server must be up and running before you configure your appliance to use it.
○ Port 9443 is the default port and cannot be changed.
● For the Connect Directly option:
○ If your network connection uses a proxy server, specify the IP address of the proxy server.
NOTE: The proxy server must be up and running before you configure your appliance to use it.
○ Use the controls to select the number of the port that will be used to connect to the proxy server in your network.
NOTE: Port 3128 is the default that is used when the port is not specified and Support Connectivity is enabled
with Connect Directly and a firewall is employed between the appliance and a Proxy server. If the default or
user-specified port is closed, communication with the appliance through the port is not available.
9. Depending on which type of Support Connectivity option you select, do one of the following:
● For the Connect Directly option, go to the next step.
● For the Connect via Secure Connect Gateway option, select Test Connection for each configured gateway server to
check the status of the connection to the gateway server.
NOTE: If the connectivity status appears to remain as Transitioning and does not change after several minutes
(the time it should take to test connectivity), contact your service provider.

10. The Connect to CloudIQ checkbox is selected by default; if you do not want to send files to CloudIQ and be able to use the
Cybersecurity application, clear the checkbox; otherwise, leave the checkbox selected.
11. The Remote Support checkbox is selected by default; if you do not want to allow support engineers who are authorized by
your service provider to securely troubleshoot your system, clear the checkbox; otherwise, leave the checkbox selected.
12. Select Send Test Alert to send a test alert to your service provider to ensure end-to-end connectivity.

PowerStore Manager 71
13. Select Apply to retain the Support Connectivity configuration information.

Manage Support Connectivity settings

Prerequisites
Support Connectivity has been initially configured and the associated End User License Agreement (EULA) has been accepted.

About this task

You can change the Support Contacts and Connection Type configuration settings, view the status of the feature, test the
connection to your service provider, and send a test alert to your service provider.

Steps
1. In PowerStore Manager, select Settings and, under Support, select Support Connectivity.
The Support Connectivity page appears.
2. To modify the configuration settings of Support Connectivity, do one or more of the following actions as needed:
NOTE: You must click Apply before you can navigate from either Support Contacts or Connection Type after
changes have been made under either tab; otherwise, a prompt appears asking whether to cancel the navigation move
or to discard the information that you typed in.

● Change or delete the information for the Primary Contact or Secondary Contact, or both.
NOTE: With PowerStore operating system 2.1. and later releases, this feature cannot be enabled unless the Primary
Contact information with the required values is provided. Also, the Primary Contact information can only be
deleted when the feature is disabled. The First Name and Last Name of the Primary Contact are mandatory,
as well as the Email or Phone (at least one is required) of the Primary Contact. Providing information for the
Secondary Contact is optional. Your Support Connectivity contact information is critical for quick response to
support issues and must be accurate and current. Also, you can view the Privacy Policy and the Telemetry Notice by
selecting the related link in the Support Contacts introductory text.
● Click the Enabled/Disabled control to enable or disable Support Connectivity.
NOTE: The connection status will not change until after you click Apply.

NOTE: With PowerStore operating system version 4.0 or later versions, Support Connectivity runs a precheck as
part of its enablement process to proactively confirm that it is ready to be enabled. If the precheck determines that
enabling Support Connectivity will fail, it remains disabled. Also, notifications are provided along with actionable steps
to take to remedy issues that are discovered during the precheck. See Support Connectivity enablement precheck
for more information about the Support Connectivity precheck.
● Change the Connection Type option you intend to use and provide any related information that is required.
○ For the Connect via Secure Connect Gateway option:
￭ Specify the IP address of each gateway server, the primary server and, if available, the backup server.
NOTE: Each gateway server must be up and running before you configure your appliance to use it.
￭ Port 9443 is the default port and cannot be changed.
○ For the Connect Directly option:
￭ If your network connection uses a proxy server, specify the IP address of the proxy server.
NOTE: The proxy server must be up and running before you configure your appliance to use it.
￭ Use the controls to select the number of the port that will be used to connect to the proxy server in your
network.
NOTE: Port 3128 is the default used when the port is not specified and Support Connectivity is enabled with
Connect Directly and a firewall is employed between the storage system and a Proxy server. If the default or
user-specified port is closed, communication with the storage system through the port will be unavailable.
● For the Connect via Secure Connect Gateway option, select Test Connection for the configured gateway servers to
check the status of the connection to the gateway servers.
NOTE: If the connectivity status appears to remain as Transitioning and does not change after several minutes
(the time it should take to test connectivity), contact your service provider.
● Send a test alert to your service provider to ensure end-to-end connectivity.

72 PowerStore Manager
 ● Change the Connect to CloudIQ setting.
NOTE: To send files to CloudIQ and be able to use the Cybersecurity application, select the checkbox; otherwise,
clear the checkbox.
● Change the setting for Remote Support.
NOTE: If you want to allow support engineers authorized by your service provider to securely troubleshoot your
system, select the checkbox; otherwise, clear the checkbox.
3. Select Apply to retain the Support Connectivity configuration information.

CloudIQ
CloudIQ is a cloud-based application that allows users to monitor system performance in near real-time across multiple
PowerStore clusters and perform basic service actions. CloudIQ uses logs, system configuration, alerts, performance metrics,
capacity metrics, and capacity forecast data that Support Connectivity collects from PowerStore clusters. CloudIQ provides
dashboard views of all connected clusters, showing key information such as performance, capacity trending, and capacity
predictions. CloudIQ also provides proactive serviceability that informs the user about issues before they occur and provides the
user with simple, guided remediation.

NOTE: Support Connectivity must be enabled on the cluster to send data to CloudIQ.

Users can enable CloudIQ during the configuration of Support Connectivity on a PowerStore cluster. CloudIQ support is enabled
by default when any Support Connectivity option is enabled. When Support Connectivity and CloudIQ are enabled, CloudIQ
can be launched directly from PowerStore Manager. Users can also log in to the Dell site for CloudIQ with their valid service
credentials to view their PowerStore clusters in CloudIQ.
NOTE: Once CloudIQ is enabled, it is possible to disable Support Connectivity without changing the CloudIQ setting.
Without Support Connectivity, data is not collected and sent to CloudIQ, but if Support Connectivity is re-enabled, the
system remembers the CloudIQ setting and immediately resumes sending data to CloudIQ. Disabling CloudIQ support does
not disable the transfer of service-related telemetry data and data proactive collections that are provided through Support
Connectivity.

System Health
NOTE: This feature is only applicable when Support Connectivity is enabled on the cluster and a bi-directional connection
exists between PowerStore and CloudIQ.
System Health is shown in the Overview tab of the Dashboard page in PowerStore Manager. The health score provides an
insight into how the system is performing. The health score is based on PowerStore alerts that are sent in the telemetry data.
System Health also includes five attributes that appear as icons for Components, Configuration, Capacity, Performance, and
Data Protection, respectively, along with issues and their associated remediation steps.

Cybersecurity
NOTE: Support Connectivity and CloudIQ must be enabled on the storage system to enable use of the Cybersecurity
application.
Cybersecurity is a software as a service cloud-based storage security analytics application. It provides security assessment
and measures the overall cybersecurity risk level of appliances using intelligent, comprehensive, and predictive analytics.
Cybersecurity uses Support Connectivity to collect system logs, system configurations, security configurations and settings,
alerts, and performance metrics from your PowerStore system.

Alert settings
PowerStore alerts inform administrators of actionable events that occur on the PowerStore cluster. These alerts can be
reported as shown in the following table.

PowerStore Manager 73
Table 12. Alert settings
Alert notification Description
type
Visual notification PowerStore Manager displays informational messages when users log in to the interface and in real
time to indicate when alert conditions occur. These messages provide basic information about the
alert condition.
NOTE: PowerStore visual alert notifications are not configurable.

Email notification Enables you to specify one or more email addresses to which to send alert messages. You can
configure the following settings:
● Email addresses to which to send storage system alerts.
● Severity level (Critical, Major, Minor, and Info) required for email notification.
NOTE: For PowerStore alert email notification to work, you must configure a target SMTP
server for the PowerStore cluster. PowerStore does not have an option of authentication to
an SMTP mail server. If your mail server requires all clients to authenticate to relay an email,
PowerStore cannot send email alerts through that mail server.

SNMP traps Transfer alert information to designated SNMP Managers (trap destinations) that act as repositories
for generated alert information by the PowerStore cluster. You can configure the following settings:
● Network Name or IP address of a network SNMP Manager
● Port number
NOTE: The default port set for SNMP is 162. Valid port values are 162 or between 1024–
49151.
● Minimal Severity Level of Alerts: Notifications are sent for the configured severity level or higher.
● Version: Version used for SNMP traps (v2c or v3)
● Trap Community String: SNMP community string (applicable only to v2c SNMP destination)
● Security Level: Authentication security level (applicable only to a v3 SNMP destination)
● Username: Security Name of the SNMPv3 user sending the message (applicable only to a v3
SNMP destination)
● Password: Generated (applicable only to a v3 SNMP destination)
● Authentication protocol: Hashing algorithm used for SNMP traps (SHA or MD5) (applicable only
to a v3 SNMP destination)
● Privacy protocol: Encryption algorithm used for SNMP traps (TDES or AES) (applicable only to a
v3 SNMP destination)
Support Connectivity Support Connectivity provides an IP-based connection that enables your service provider to receive
error files and alert messages from the PowerStore cluster, and to perform remote troubleshooting
resulting in a fast and efficient time to resolution.
NOTE: For Support Connectivity to work, you must enable it on the PowerStore cluster.

CloudIQ CloudIQ is a Dell-hosted service that uses data (logs, system configuration, alerts, performance
metrics, and capacity metrics and capacity forecast data) collected through Support Connectivity to
allow users to monitor performance in near real-time and utilization and health time across multiple
PowerStore clusters and perform basic service actions. The CloudIQ interface is accessible through
a web browser at any time and from any location.
NOTE: Support Connectivity must be enabled on the storage system to connect and send data
to CloudIQ.

Configure email notifications

About this task
You can configure your system to send alert notifications through email using an SMTP server.
NOTE: For the storage system alert email mechanism to work, a target SMTP server must be configured for the storage
system.
Using PowerStore Manager, do the following:

74 PowerStore Manager
Steps
1. Select Settings, and then select SMTP Server under Networking.
2. To access the SMTP server settings, change the status to Enabled.
3. Add the SMTP server address and the email address that notifications should be sent from and click Apply.
4. Select Settings, and then select Email Notifications under Support.
5. To add email recipients, click Add under Email Subscribers.
6. Type the email address that you want to send alert notifications to. When you add an address, you can select the severity
level of the alert notifications that are sent to that address. (Optional) To verify whether email addresses are entered
correctly, select the target email addresses, and then click Send Test Email.

Configure SNMP
About this task
You can configure your system to send alert information to up to 10 designated SNMP Managers (trap destinations).
NOTE: Only notifications are supported.

The authoritative Local Engine ID used for SNMPv3 messages is given as a hexadecimal string. It is discovered and added
automatically.
NOTE: To verify the Local Engine ID select Settings, and under Networking, select SNMP. The Local Engine ID
appears under Details.
Using PowerStore Manager, do the following:

Steps
1. Select Settings and, under Networking, select SNMP.
The SNMP card appears.
2. To add an SNMP Manager, click Add under SNMP Managers.
The Add SNMP Manager slide out appears.
3. Depending on the version of SNMP, configure the following information for the SNMP Manager:
● For SNMPv2c:
○ Network Name or IP address
○ Port
○ Minimal Severity Level of Alerts
○ Version
○ Trap Community String
● For SNMPv3
○ Network Name or IP address
○ Port
○ Minimal Severity Level of Alerts
○ Version
○ Security Level
NOTE: Depending on the security level selected, additional fields appear.
￭ For the level None, only Username appears.
￭ For the level Authentication only, Password and Authentication Protocol appear along with Username.
￭ For the level Authentication and privacy, Password, Authentication Protocol, and Privacy Protocol
appear along with Username.
○ Username
NOTE: When the Security Level of None is selected, the username must be NULL. When a Security Level of
Authentication only or Authentication and privacy is selected, the username is the Security Name of the
SNMPv3 user sending the message. The SNMP username can contain up to 32 characters in length and include
any combination of alphanumeric characters (uppercase letters, lowercase letters, and numbers).
○ Password
NOTE: When a Security Level of either Authentication only or Authentication and privacy is selected, the
system determines the password.

PowerStore Manager 75
 ○ Authentication Protocol
NOTE: When a Security Level of either Authentication only or Authentication and privacy is selected, select
either MD5 or SHA256.
○ Privacy Protocol
NOTE: When a Security Level of Authentication and privacy is selected, select either AES256 or TDES.
4. Click Add.
5. (Optional) To verify whether SNMP Manager destinations can be reached and the correct information is received, click Sent
Test SNMP Trap.

Common Event Enabler Common Event Publishing

Agent
The Common Event Enabler (CEE) Common Event Publishing Agent (CEPA) consists of applications that are designed to
process SMB and NFS file and directory event notifications. CEPA must be enabled and an event publishing pool must be
created on the NAS server, which defines the CEPA servers and the specific events that trigger notifications. Once the NAS
server is configured, enable events publishing on the file systems from which you want to receive events. Depending on the type
of file system, you can enable NFS or SMB, or both for events publishing. When a host generates an event on the file system
over SMB or NFS, this information is forwarded to the CEPA server. The CEPA software on the server receives and publishes
this event, enabling it to be processed by third party software.
Some of the common uses for CEPA include file auditing, centralized quota management, and search/indexing. An example of
file auditing is logging an event any time a file or directory is created, renamed, or deleted. The following are types of events
that can be logged:
● Pre Events - Events are sent to the CEPA server for approval prior to being executed.
● Post Events – Events are sent to the CEPA server after they occur for logging or auditing purposes.
● Post Error Events – Error events are sent to the CEPA server after they occur for logging or auditing purposes.

Understanding the Common AntiVirus Agent (CAVA)

Common AntiVirus Agent (CAVA) provides an antivirus solution to clients using a NAS server. It uses an industry-standard SMB
protocol in a Windows Server environment. CAVA uses third-party antivirus software to identify and eliminate known viruses
before they infect files on the storage system.

Why is antivirus important?

The storage system is resistant to the invasion of viruses because of its architecture. The NAS server runs data access in
real-time using an embedded operating system. Third parties are unable to run programs containing viruses on this operating
system. Although the operating system is resistant to viruses, Windows clients that access the storage system require virus
protection. Virus protection on clients reduces the chance that they will store an infected file on the server, and protects them
if they open an infected file. This antivirus solution consists of a combination of the operating system, CAVA agent, and a
third-party antivirus engine. The CAVA software and a third-party antivirus engine must be installed on a Windows Server in the
domain.
For additional information about CAVA, which is part of Common Event Enabler (CEE), see Using the Common Event Enabler on
Windows Platforms and PowerStore Configuring SMB Guide on Dell Support. Also, see the PowerStore Manager online help.

Malware detection
Malware detection is performed during PowerStore engineering cycle. Dell ensures that PowerStore systems are free of
malware before the product ships. Because the PowerStore system is an appliance, additional software cannot be installed;
therefore, malware detection is not provided or needed in deployed PowerStore systems.

76 PowerStore Manager
 4
Data at Rest Encryption
This section contains the following topics:
Topics:
• Data at Rest Encryption
• Encryption activation
• Encryption status
• Key management
• Keystore backup file
• External key management
• Repurpose a drive in an appliance with encryption enabled
• Replacing a base enclosure and nodes from a system with encryption enabled
• Resetting an appliance to factory settings

Data at Rest Encryption

Data at Rest Encryption (D@RE) in PowerStore uses Self-Encrypting Drives (SEDs) by respective drive vendors. These SEDs
are for primary storage (NVMe SSD, NVMe SCM, and SAS SSD).
NOTE: See the PowerStore Simple Support Matrix document at dell.com/powerstoredocs for specific appliance model
information about SEDs.
Encryption is performed within each drive before the data is written to the media. This encryption protects the data on the drive
against theft or loss and attempts to read the drive directly by physically deconstructing the drive. The encryption also provides
a means to quickly and securely erase information about a drive to ensure that the information is not recoverable. In addition
to protecting against threats that are related to physical removal of media, you can readily repurpose media by destroying the
encryption key that is used for securing the data that is previously stored on that media.
Reading encrypted data requires the authentication key for the SED to unlock the drive. Only authenticated SEDs are unlocked
and accessible. Once the drive is unlocked, the SED decrypts the encrypted data back to its original form.
The PowerStore appliance must contain all SEDs. If you try to add a nonself-encrypting drive to an appliance, the appliance
raises an error.

Encryption activation
The Data at Rest Encryption feature on PowerStore appliances is set at the factory.
The encryption feature is disabled for countries that are not allowed to import an appliance that supports encryption. The
encryption feature is enabled by default for countries that are allowed to import an appliance that supports encryption. Once
encryption is enabled, it cannot be disabled.

NOTE: Appliances that do not support Data at Rest Encryption cannot be added to a cluster with encrypted appliances.

Encryption status
The encryption status is reported at the following levels:
● Cluster level
● Appliance level
● Drive level
Cluster level encryption status reflects whether encryption is enabled on the appliances.

Data at Rest Encryption 77

The encryption status of the cluster is displayed as one of the following:
● Encrypted – Encryption capability is enabled on the cluster.
● Unencrypted – Encryption capability is not supported on the cluster.
The drive level encryption status is provided for each drive in an appliance and is displayed as one of the following:
● Encrypted – The drive is encrypted. This status is the typical state of a drive that is encryption capable.
● Processing – The appliance is enabling encryption on the drive. This status can be seen during the initial activation of
encryption on an appliance or during the addition of new drives to a configured appliance.
● Disabled – The drive cannot have encryption enabled due to country or region specific import restrictions. If any drives
report this status, all drives in the cluster will also report the same status.
● Not Supported – The drive does not support encryption.
● Foreign – The drive is supported, but it is locked by another appliance. The drive must be decommissioned before it can be
used.

Key management
An embedded key manager service (KMS) runs on the active node of each PowerStore appliance. This service manages the
local keystore file lockbox storage to support automatic encryption key backup to system and boot drives. It also controls the
Self-Encrypting Drive (SED) lock and unlock process on the appliance and is responsible for managing the local keystore content
for the appliance. The local keystore file is encrypted with a 256-bit AES key and the keystore file lockbox storage leverages
RSA’s BSAFE technology.
The KMS automatically generates a random authentication key for SEDs during the initialization of the appliance. Each drive has
a unique authentication key, including those that are added to the appliance later on, that is used in the SED lock and unlock
processes. A key encryption key encrypts authentication and encryption keys in the keystore file storage and in flight within the
appliance. Media encryption keys are stored on the dedicated hardware of the SEDs and cannot be accessed. When encryption
is enabled, all the authentication keys are stored within the appliance.

Keystore backup file

The KMS supports the creation and download of an off-appliance backup of the keystore archive file. The off-appliance backup
reduces the chances of a catastrophic key loss, which would render an appliance or cluster unusable. If a particular appliance
is unavailable when a cluster keystore backup is initiated, the overall operation succeeds, but a warning is issued that the
backup does not contain keystore files for all appliances in the cluster and that the operation should be retried when the offline
appliance is available.
NOTE: The primary appliance in a cluster contains a cluster keystore archive file that contains a copy of keystore backups
from each appliance that is discovered in the cluster, including the primary appliance.
When changes to the configuration of a system within the cluster occur that result in changes to the keystore, it is
recommended that you generate a new keystore archive file for download. Only one backup download operation of the keystore
archive file can be run at a time.
NOTE: It is recommended that you download the generated keystore archive file to an external, secure location. If the
keystore files on a system become corrupted and inaccessible, that system enters service mode. In this case, the keystore
archive file and a service engagement are required for resolution.
A user role of Administrator is required to back up the keystore archive file. To back up the keystore archive file, click Settings
and select Encryption under Security. Then, click Download Keystore Backup under Lockbox on the Encryption page.

NOTE: To restore the keystore backup in case there is a failure, contact your service provider.

External key management

Support for external key management is provided by using the Key Management Interoperability Protocol (KMIP). KMIP defines
how a client operates with an external key manager.
KMIP provides an additional layer of security in addition to the encryption of the drives on a PowerStore appliance. All drive
keys are encrypted with a master key value called the Key Encryption Key (KEK). When KMIP is enabled, the KEK is sent to and

78 Data at Rest Encryption

then managed by an externally managed server, a KMIP server. Each appliance in a PowerStore cluster has its own KEK that is
transferred to the KMIP server. The transfer is done using the KMIP protocol.

NOTE: PowerStore operating system versions 3.0 and later support KMIP version 1.4.

The benefit of using an externally managed key server is to protect user data in the event the appliance is stolen or repurposed
without being properly initialized. Before attempting to fetch the KEK from the external kmip server, the first attempt is to
push the KEK down from the alive node in the appliance (provided one node has not gone down). If both nodes are down for
a reboot or powered off, the KEK in memory on each node is not available. The only option is to fetch the KEK from the KMIP
server. In this case when the appliance boots, the node attempts to fetch the KEK from (one or more) KMIP servers. If the KEK
cannot be retrieved, the appliance transitions to service mode where limited operations are allowed. The data remains locked
and encrypted, and the system does not boot fully until the KEK can be retrieved and validated. When the KMIP feature is
disabled, KEK is placed back in the lockbox for the appliance. The KEK is managed again by the internal key manager (KMS).
After the KEK is stored in the local lockbox, the KEK entry on the KMIP server is deleted.
PowerStore supports up to a maximum of five KMIP servers. All KMIP servers must be of the matching vendor type and use the
same CA for certificates.
NOTE: PowerStore supports the following KMIP server vendors and each vendor can have different authentication
requirements that may or may not require a username or password, or both. Examples:
● For IBM Security Guardium Key Lifecycle Manager, it is recommended to use Global ID for the cluster wide unique ID. Do
not specify a password.
NOTE: The Global ID can be found using Unisphere. Under Settings, select Cluster, then Properties. The IBM
Secure Life Cycle Key Manager only allows 12 characters for the Global ID. Therefore, an ID of PSb2e9d5ead27a
would be represented as PSb2e9d5ead2.
● For Thales CipherTrust Manager, a username and password are required. Also, at least one Cipher-Block-Chaining
(CBC) cipher must be enabled on the KMIP interfaces and all the nodes on those KMIP interfaces must use the same
certificate.
● For Thales Vormetric Data Security Manager, a username and password should not be specified; client authentication
uses the client certificate of the PowerStore appliance.
● For Dell CloudLink, the username and password are required.
● For Fornetix VaultCore, a username and password should not be specified; client authentication uses the client
certificate of the PowerStore appliance.
● For Fortanix, the username and password are optional. If they are used, both the username and password are required.
Otherwise, neither should be used.
For the latest list of supported Key Managers and their associated vendors and federal compliance related information, see
the Simple Support Matrix for the storage system on the support website.
Before KMIP can be initially enabled, you must import a signed Mutual Authentication Certificate and a copy of the associated
Server CA Certificate for the KMIP servers. The signed Mutual Authentication Certificate provides authentication between
the PowerStore appliance and your KMIP server. Once both certificates have been successfully imported, you can enable and
configure the KMIP server configuration.
NOTE: Some KMIP servers do not have internal CAs, and an external CA is required to sign a client-side CSR. Use the
REST API to import a server private key (in PKCS8 format) along with a client certificate provided by the KMIP server
through the credential store REST API. The private key can be converted to PKCS8 format using the following options in
openssl:

sudo openssl pkcs8 -v1 PBE-SHA1-3DES -topk8 -in <path/to/private_key.key> -out

<path/to/new/formatted/pkcs8.pem>

The format of the REST call with the private key (pkcs8 format) and certificate in string format is as follows:

curl -s -k -u "<user:password>" -H "Content-Type:application/json" -X POST

-d '{"type": "Client", "service": "KMIP_HTTP","scope": "KMIP", "is_current":
true, "private_key": "<pkcs8_formmatted_private_key_goes_here_in_string_format>",
"passphrase": "<passphrase_used_to_create_pkcs8>", "certificate":
"<client_certificate_in_string_format>"}' "https://<Trident_Cluster_IP>/api/rest/
x509_certificate" | jq '.'

Data at Rest Encryption 79

Generate a Certificate Signing Request
Prerequisites
Before you generate a Certificate Signing Request (CSR), ensure that you have obtained the following information for the
request:
● Common Name
● IP address
● DNS Name
● Organization
● Organization Unit
● Locality
● State
● Country
● Key Length
● (Optional) Passphrase

About this task

Generating a CSR is applicable to a Mutual Authentication Certificate, which is used in two-way authentication between
PowerStore and the KMIP server. To generate a CSR using the PowerStore Manager, do the following:

Steps
1. Select Settings and under Security select KMIP.
The KMIP (Key Manager Interoperability Protocol) page appears.
2. Select Generate CSR.
The Generate CSR slide out appears.
3. Type in the information that is used to generate the CSR.
4. Click Generate.
The Generate CSR slide out changes to show the next steps that must be taken along with the certificate text.
5. Click Copy to clipboard to copy the certificate text to your clipboard.
6. Click Close.
7. The certificate authority (CA) must sign the certificate so that it can be imported as a Mutual Authentication Certificate.

Import a certificate for KMIP

Prerequisites
Before importing a certificate, ensure that you know the location of the certificate file or have the certificate text available to
copy and paste for import.

About this task

To import a certificate using the PowerStore Manager, do the following:

Steps
1. Click Settings and, under Security, select KMIP.
The KMIP (Key Manager Interoperability Protocol) page appears.
2. Under Certificates, select Import and select the type of certificate to import.
The slide out for the respective certificate appears.
3. Do one of the following:
● Select Select Certificate File, then locate and select the file to import.
● Select Paste Certificate Text, then copy and paste the certificate text in the text box.
4. Select Import.
The certificate detail information should appear in the list under Certificates.

80 Data at Rest Encryption

Enable KMIP server configuration
Prerequisites
A signed Mutual Authentication Certificate and a copy of the Server CA Certificate for the KMIP servers have been imported.
These two certificates are required to initially enable the KMIP server configuration.
Ensure that you have obtained the following KMIP server details:
● Device ID or username, if required
● Password, if required
● Port
● Timeout for verification
● IP address or Fully Qualified Domain Name (FQDN) for each KMIP server
NOTE: All KMIP servers must be of matching vendor type and use the same CA for the certificates.

About this task

To enable the KMIP server configuration using PowerStore Manager, do the following:

Steps
1. Click Settings and, under Security, select KMIP.
The KMIP (Key Management Interoperability Protocol) page opens.
2. Under Server Configuration, click the toggle control.
The KMIP Configuration slide out opens.
3. If required, type in the Device ID or username for the KMIP server.
4. If required, type in the password for the KMIP server.
5. If required, a different port than the default port 5696 can be selected.
6. If required, a different timeout than the default timeout of five seconds can be selected.
7. Type in the IP address or FQDN of each KMIP server.
A maximum of five KMIP servers can be added.
8. Click Apply.
The KMIP Configuration slide out closes, and ModifyKmipConfigCommand opens. The display indicates that a job has
started and shows the percentage of completion.
NOTE: To see more details specific to the job, click the ModifyKmipConfigCommand link. The Job Details panel
opens. When the job is finished, the Server Configuration toggle control should move to the right and Disabled
changes to Enabled. Also, the configured KMIP server information and the status of the connectivity between
PowerStore and each KMIP server is shown.
.

Manage KMIP settings

About this task
You can change the KMIP configuration settings of the KMIP servers, delete KMIP servers, and validate the status of the KMIP
servers. You can also import either a Server CA Certificate or a Mutual Authentication Certificate for two-way authentication,
delete a certificate, and generate a Certificate Signing Request (CSR).

Steps
1. In PowerStore Manager, select Settings and, under Security, select KMIP.
The KMIP (Key Manager Interoperability Protocol) page appears and lists information about the KMIP servers and
associated certificates for authentication.
2. For certificates, click:

Data at Rest Encryption 81

 Option Description
Import Select whether to import a Server CA Certificate or a Mutual Authentication Certificate for two-way
authentication. Depending on the type of certificate selected to import, either the Import Server CA
Certificate or Import Mutual Authentication Certificate slide-out appears.
NOTE: For either type of certificate, you have the options either to select a certificate file to import or
copy and paste the certificate text to import. A certificate that is imported applies to each KMIP server
that is configured.

CAUTION: Importing a new CA Certificate will replace the existing certificate that is used by
the PowerStore cluster.

Delete To delete a selected certificate.

NOTE: Both a signed Mutual Authentication Certificate and a copy of the associated Server CA
Certificate for the KMIP servers must be available for the Server Configuration to be enabled.

Generate The Generate CSR slide-out appears. Provide the information that is needed for generating a CSR. Once
CSR the CSR is generated and appears in the slide-out, copy the certificate text to your clipboard. Then, have the
certificate signed by the certificate authority (CA). Import the signed certificate to PowerStore. A CSR can
be signed by your CA and imported into PowerStore as a Mutual Authentication Certificate.
3. To modify the KMIP Server Configuration settings, select Edit Configuration and do any of the following on the KMIP
Configuration slide out panel:
● Change the KMIP Configuration settings as needed.
● To delete a KMIP server, select the checkbox next to the IP address or FQDN of the KMIP server or, to delete multiple
KMIP servers at one time, select the checkbox next to the IP address or FQDN of each KMIP server to be deleted, then
click Delete.
Click Apply when all the changes have been made.
4. To manually validate the connectivity between the PowerStore cluster and the KMIP servers, select Validate.
NOTE: Validation of the connectivity to each server is automatically run every 30 minutes.

Repurpose a drive in an appliance with encryption

enabled
A self-encrypting drive (SED) is locked when an appliance is initialized or when it is inserted into an already initialized appliance.

About this task

The drive cannot be used in another system without first being unlocked. The locked drive becomes unusable when it is inserted
into a different appliance and its encryption status appears as Foreign in the new appliance. The drive can be repurposed for
the new appliance, however, all the existing data on the drive will be lost.
Perform the following steps to repurpose a drive that has an encryption status of Foreign:

Steps
1. Record the Physical Security ID (PSID) that is on the drive label.
2. In PowerStore Manager, select Hardware, and select the appliance with the drive to repurpose from the Appliances tab.
3. On the Appliance Details page, select the Components card.
4. On the Drives tab, expand the enclosure with the drive to repurpose and select the drive.
The Encryption Status for the drive should appear as Foreign.
5. Click Repurpose Drive.
The Repurpose Drive slide-out panel appears.
6. Type the PSID of the drive in the Enter Drive PSID field and click Repurpose.

Results
The drive is repurposed in the appliance as a new drive and its encryption status changes to Encrypted.

82 Data at Rest Encryption

Replacing a base enclosure and nodes from a system
with encryption enabled
A service engagement is required to replace a base enclosure and nodes from an appliance with encryption enabled.

Resetting an appliance to factory settings

A service script, svc_factory_reset, returns a single appliance cluster back to its factory-delivered state, deleting all user
data and persistent configurations.
For multi appliance clusters, svc_factory_reset cannot be run on the secondary appliances. The service script
svc_remove_appliance must be run instead. This script returns a secondary appliance to its factory-delivered state,
deleting all user data and persistent configurations. When only the primary appliance remains in the cluster, you can run
svc_factory_reset to reset that appliance.

NOTE: It is recommended that these scripts be run by only a qualified service provider.

For more information about these scripts, refer to the PowerStore Service Scripts Guide.

Data at Rest Encryption 83

 5
Federal and DoD Standards and Compliance
This chapter contains information related to Transport Layer security (TLS), Security Technical Implementation Guide (STIG)
and Federal Information Processing Standard 140-2 (FIPS 140-2) on PowerStore.
Topics:
• Transport Layer Security
• STIG
• FIPS

Transport Layer Security

Transport Layer Security (TLS) is a cryptographic protocol that allows for secure communication over a network. PowerStore
supports TLS 1.2 by default. Earlier versions of the TLS protocol are not considered secure protocols and are not supported.
NOTE: When using import-related features on PowerStore, some older TLS cipher suites may be enabled in addition to the
default TLS configuration for the applicable feature to ensure PowerStore can establish a connection to legacy systems.
Any additional cipher suites that are enabled in this scenario only apply for those import feature-related connections or
operations and should not impact the TLS configuration of any other connections or operations outside this scope.
To determine the status of Transport Layer Security in PowerStore Manager, click Settings and, under Security, select
Compliance.

STIG
A Security Technical Implementation Guide (STIG) defines a configuration and maintenance standard for computer deployments
that are required by the US Department of Defense (DoD) Information Assurance (IA) program. These guidelines are designed
to enhance security settings and configuration options before the systems are connected to a network. More information about
the various STIGs is available.
As of PowerStore operating system version 3.5 and later, PowerStore has been STIG-hardened to meet the security
requirements of the US Federal Government. DoD Approved Products List (APL) listing is in process.

NOTE: STIG is supported in a PowerStore T model-based cluster.

Enable STIG
Prerequisites
All appliances in the PowerStore cluster must be running PowerStore operating system version 3.5 or later.
All non-FIPS compliant certificates must be removed from the appliances in the cluster before STIG and FIPS 140-2 can be
enabled.
Support Connectivity is not configured.
NOTE: If Support Connectivity is already enabled before STIG is enabled, STIG cannot be enabled. Support Connectivity
can be enabled after STIG has been enabled, however, this action may reduce the security posture of the cluster.
The cluster is fully created already.

NOTE: After entering STIG mode, more appliances cannot be added to the cluster.

Do not perform any of the following functions while enabling STIG:

84 Federal and DoD Standards and Compliance

● Local user operations
● Migration and Data Protection operations
● Non-disruptive upgrade (NDU) operations

About this task

Only an Administrator or Security Administrator can enable STIG using the REST API. Enabling STIG also enables FIPS
automatically as part of the operation and affects all the nodes on all the appliances in a cluster. It begins a process that
sequentially reboots all the nodes in the cluster, one appliance at a time. The application of FIPS and the STIG changes is
coordinated non-disruptively across the cluster.

NOTE: For information about the REST API, see the PowerStore REST API Reference Guide.

Enabling STIG should be the first step of preparing a PowerStore for use in the Secure DoD environment.
WARNING: STIG mode should only be used in a DoD environment. Enabling STIG mode is not reversible.
Changing the hardening of a PowerStore appliance from STIG mode back to normal mode requires the appliance
to be decommissioned.
To enable STIG, do the following:

NOTE: Only one attempt to enable STIG/FIPS can occur at a time.

Steps
1. Use a REST call to enable STIG.
NOTE: The following is an example of the format of the REST call to enable STIG:

curl -sk
'https://<management_IP>:443/api/rest/security_config/1?is_async=true'
--user <admin_username>:<admin_password> -X PATCH -d
'{\"is_stig_enabled\": true}' -H 'Content-Type: application/json' |
jq '.'

Where admin_user and admin_password are the credentials of a current user with the role of Administrator or Security
Administrator.

2. Use a REST call to check the progress of the STIG enable operation.
NOTE: The following is an example of the format of the REST call to check the progress of the STIG enable operation:

curl -sk --request GET 'https://<management_IP>:443/api/rest/job/<job_ID>?

select=*' --user <admin_username>:<admin_password> -H 'Content-Type:application/
json' | jq '.'

Where management_IP is the management IP address of the PowerStore appliance and job_ID is the job_ID returned
in the output from the REST call to enable STIG. Once the job_ID is no longer active, you can use the following curl
command to run until it returns true for the is_stig_enabled parameter:

curl -sk --request GET 'https://<management_IP>:443/api/rest/security_config?

select=is_stig_enabled' --user <admin_username>:<admin_password> | jq '.'

3. After the enable STIG operation has been verified as complete, close any browser tabs and open new ones to log in.

Results
The following user account settings are affected when STIG is enabled:
● Password requirements
● Login requirements and lockout period
● Session idle timeout
See User account settings when STIG is enabled for more information. Along with changes to the user account settings, the
following occur:
● A fixed Department of Defense (DoD) banner opens when the user logs in.

Federal and DoD Standards and Compliance 85

● When FIPS 140-2 is enabled, you may find that some of your existing clients can no longer communicate with the
management ports of the appliance if they do not support FIPS 140-2 Approved cipher suites.
The status of STIG and FIPS can be viewed in PowerStore Manager by selecting Settings and, under Security, selecting
Compliance.

User account settings when STIG is enabled

The following functionality for user account settings is only applicable to a PowerStore cluster that has STIG enabled:
● Additional password requirements
● Failed login requirements and lock out period
● Configuring session idle timeout

Additional password requirements

When STIG is enabled, users are required to change their password based on the following STIG new password policy rules:
● Password length should be a minimum of 15 characters.
● At least 8 characters must be different from the prior password.
● A local user password expires after 60 days by default.
NOTE: This rule does not apply to the default admin and service user passwords. Those passwords do not expire.
● The lifetime for user passwords is a minimum of 1 day.
NOTE: This rule does not apply to the default admin and service users.

If users already exist when STIG is enabled, they are required to change their password based on the STIG new password policy
rules. With the exception of the default admin user, users receive an error if the new password is not STIG compliant.
NOTE: Only the default admin user can issue REST API requests with an existing password that is not STIG compliant. The
REST API does not require the default admin user to make the password change to be STIG compliant. Only PowerStore
Manager requires the default admin to make this change.
A user with an expired password cannot log in and must have a user with an Administrator or Security Administrator role reset
the expired password. The user can then use the reset password to log in.
NOTE: The reset password of the user is shared between the admin and the local user until the local user changes the
password.

Failed login requirements and lock out period

When STIG is disabled, user accounts are not locked out due to failed log in attempts. When STIG is enabled, a user account is
locked after three successive failed log in attempts occur within 15 minutes. The account remains locked for 15 minutes after
the last failed attempt. The sessions of a locked user account are invalidated at the time of locking. A user with a locked account
either has to wait for 15 minutes before attempting to log in or has a user with an Administrator or Security Administrator role
unlock the account.

NOTE: The default admin account cannot be locked.

Session idle timeout

When STIG is disabled, the session timeout is not configurable and a user is automatically logged off the cluster after session
inactivity of one hour. When STIG is enabled in a PowerStore cluster, the behavior of the session time out changes. All account
sessions that existed at the time of STIG enablement will be automatically expired. Those users will be prompted to change
their password to meet the new policy. The session idle timeout for local users will change from a fixed 60 minutes to the
default of 10 minutes. If necessary, the default session idle time out can be changed to either 5 or 20 minutes by a user with
Administrator or Security Administrator privilege by using either PowerStore Manager or the REST API, security_config.
However, certificate-based sessions are handled differently. The default for those sessions is 60 minutes. Linux users have a
fixed session idle timeout of 10 minutes. For more information about the REST API, see the PowerStore REST API Reference
Guide.

86 Federal and DoD Standards and Compliance

 NOTE: The Session Timeout selection only appears in PowerStore Manager under Settings > Security when STIG is
enabled.

FIPS
Federal Information Processing Standard 140-2 (FIPS 140-2) is a standard that describes US Federal government requirements
that IT products should meet for Sensitive, but Unclassified (SBU) use. The standard defines the security requirements that
must be satisfied by a cryptographic module used in a security system protecting unclassified information within IT systems. To
learn more about FIPS 140-2, refer to FIPS 140-2 publication.
FIPS is automatically enabled as part of the operation to enable STIG and affects all the nodes on all the appliances in a cluster.
PowerStore supports FIPS 140-2 for the SSL modules that handle client management traffic. Management communication into
and out of an appliance is encrypted using SSL. As part of this process, the client and the storage management software
negotiate a cipher suite to use in the exchange. FIPS 140-2 restricts the negotiable set of cipher suites to only those that
are listed in the FIPS 140-2 Approved Security Functions publication. If FIPS 140-2 is enabled, you may find that some of your
existing clients can no longer communicate with the management ports of the appliance if they do not support FIPS 140-2
Approved cipher suites.
STIG cannot be enabled in a PowerStore cluster when non-FIPS-compliant certificates exist in the certificate store of the
appliances in the cluster. All non-FIPS compliant certificates must be removed from the appliances before STIG and FIPS 140-2
are enabled.

Federal and DoD Standards and Compliance 87

 A
TLS cipher suites
This appendix contains the following information:
Topics:
• Supported TLS cipher suites

Supported TLS cipher suites

A cipher suite defines a set of technologies to secure your TLS communications:
● Key exchange algorithm (how the secret key used to encrypt the data is communicated from the client to the server).
Examples: RSA key or Diffie-Hellman (DH)
● Authentication method (how hosts can authenticate the identity of remote hosts). Examples: RSA certificate, DSS
certificate, or no authentication
● Encryption cipher (how to encrypt data). Examples: AES (256 or 128 bits)
● Hash algorithm (ensuring data by providing a way to determine if data has been modified). Examples: SHA-2 or SHA-1
The supported cipher suites combine all these items.
NOTE: Security is improved in PowerStore version 2.0.x with the removal of weak ciphers, such as those starting with
TLS_RSA_. For example, TLS_RSA_WITH_AES_128_CBC_SHA is not supported.
TLS cipher suites supported on the appliance lists the OpenSSL names of the supported TLS cipher suites for the appliance and
the associated ports.

Table 13. TLS cipher suites supported on the appliance

Cipher Suites Protocols Ports
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS 1.2 443, 8443
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS 1.2 443, 8443

NOTE: When using import-related features on PowerStore, some older TLS cipher suites may be enabled in addition to the
default TLS configuration for the applicable feature to ensure PowerStore can establish a connection to legacy systems.
Any additional cipher suites that are enabled in this scenario only apply for those import feature-related connections or
operations and should not impact the TLS configuration of any other connections or operations outside this scope.

88 TLS cipher suites