Reference Guide
NOTE: The VM Administrator role is strictly used as a means to register certificates.
○ for local users use the syntax: local/<username>
○ for LDAP users use the syntax: <domain>/<username>
● Password associated with this user.
The PowerStore Manager credentials used here are only used during this initial step of the connection. If the PowerStore
Manager credentials are valid for the target cluster, the certificate of the vCenter Server is automatically registered with the
cluster. This certificate is used to authenticate all subsequent requests from the vCenter. No manual steps are required to install
or upload this certificate to the VASA Provider. If the certificate has expired, the vCenter must register a new certificate to
support a new session. If the certificate is revoked by the user, 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 will start a new one.
● 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. It adds the VMCA certificate to its truststore, then issues a certificate signing request,
and replaces its self‐signed certificate with the VMCA signed certificate. Future connections will be authenticated by the VASA
Provider using the client 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.
Authentication and access 15