Dell PowerStore 1000T EMC PowerStore Security Configuration Guide - Page 15

CHAP authentication, Configuring CHAP

Page 15 highlights

Storage Monitoring Service(SMS) certificate validated against the previously registered 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. 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 associated with each function call from the vCenter Server. The VASA Provider uses the VMCA certificate 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 will perform 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 will establish a new SSL connection and register 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 obtained from SMS. 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, similar to a password, that is known to both the authenticator and the peer. There are two variants of 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 user name 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. Each iSCSI target presented by the group is authenticated by the iSCSI initiator. When an initiator tries to connect to a target, the target provides a user name and password to the initiator. The initiator compares the supplied user name and password to information it holds. If they match, the initiator can connect to the target. NOTE: If CHAP will be used in your environment, 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 1. iSCSI CHAP Discovery mode limitations CHAP Mode Single Mode (initiator enabled) Mutual Mode (initiator and target enabled) Discovery PowerStore will not authenticate (challenge) the host. Authentication cannot be used to preclude the discovery of targets. This does not result in unintended access to user data. PowerStore will not respond to an authentication request (challenge) from a host, and discovery will fail if the host challenges PowerStore. Normal Works as expected. Credentials are tested Works as expected. Credentials are by PowerStore. transferred by PowerStore. 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, while also taking the CHAP settings into account. 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. 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. Authentication and access 15

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41

Storage Monitoring Service(SMS) certificate validated against the previously registered 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.
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 associated with each function call from the vCenter
Server. The VASA Provider uses the VMCA certificate 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 will
perform 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 will establish a new SSL
connection and register 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 obtained from SMS.
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, similar to
a password, that is known to both the authenticator and the peer. There are two variants of 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 user name 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. Each iSCSI target presented by the group is authenticated by the iSCSI initiator. When an initiator tries to
connect to a target, the target provides a user name and password to the initiator. The initiator compares the supplied user name and
password to information it holds. If they match, the initiator can connect to the target.
NOTE:
If CHAP will be used in your environment, 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 1. iSCSI CHAP Discovery mode limitations
CHAP Mode
Single Mode (initiator enabled)
Mutual Mode (initiator and target
enabled)
Discovery
PowerStore will not authenticate
(challenge) the host. Authentication cannot
be used to preclude the discovery of
targets. This does not result in unintended
access to user data.
PowerStore will not respond to an
authentication request (challenge) from a
host, and discovery will fail if the host
challenges PowerStore.
Normal
Works as expected. Credentials are tested
by PowerStore.
Works as expected. Credentials are
transferred by PowerStore.
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, while also taking the CHAP settings into account.
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.
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.
Authentication and access
15