Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > Symmetrix Access Controls
Many product applications, such as Unisphere for PowerMax, TimeFinder, and SRDF can issue management commands to any device in a PowerMax array. By default, anyone with access to PowerMax-based management software can execute any function on any PowerMax device.
Shared systems such as these may be vulnerable to one host, accidentally or intentionally, tampering with another’s devices. To prevent this, the symacl command can be used by an administrator of the PowerMax storage site to set up and restrict host access to defined sets of devices, or access pools, across the various PowerMax arrays.
This SYMCLI component supports Symmetrix Access Control requirements. The Access Control command allows you to set up and maintain an access-controlled environment over the PowerMax access pools. The command, symacl, sets up access control mechanisms and changes access control entries in the access control database[56].
Note: Symmetrix Access Control is not supported on the PowerMax 2500/8500.
A PowerMax-based access control database contains all the mechanisms or information to govern access to PowerMax access pools.
Information about the following access control mechanisms comprise the access control database:
Implementing the security settings will require modifying Solutions Enabler files as well as executing SYMCLI commands. On SRM Windows this is a straightforward process, but on the SRM Appliance, since the local Solutions Enabler runs inside a Docker container, the container must be accessed directly to run any SYMCLI commands, though the SE configuration files can be changed through the SRM Appliance Management.
Start by downloading the configuration archive from either the protection or recovery site shown in Figure 180.
Figure 180. Download configuration archive
Extract the archive file keeping the existing directory structure. As the Appliance is Linux-based, it is best to extract and edit the files on a similar OS. If Windows is used, be sure there are no extra characters in the file when saving it. There is no syntax checking of the files when the archive is uploaded, and any incorrect information may cause the software to operate incorrectly or not at all.
Modify the necessary SE files. When complete, tar and compress all the configuration files, maintaining the directory structure. Upload the configuration archive using the SRM Appliance Management interface in Figure 181 for both the protection and recovery sites.
Figure 181. Uploading SRDF SRA configuration archive
Whenever SE files are changed, the SRDF SRA must be reloaded so that the changes can be incorporated. Using the same SRM Management interface, run a Reload as in Figure 182.
Figure 182. Reloading SRDF SRA configuration archive
During a reload, the SE daemons will be restarted and use the new settings.
When it is necessary to run SYMCLI commands, the Docker container must be accessed directly.
In order to run Solutions Enabler commands on the SRM Appliance, it is necessary to access the running Docker container directly. Docker provides the commands to do this. Follow the outlined steps below.
An example of these steps is shown in Figure 183.
Figure 183. Running SYMCLI in Docker container
The first step in the process of configuring SYMACLs is to create the access control groups by gathering the SYMACL unique identifiers.
If the Solutions Enabler servers are configured to be local (they have direct access to Gatekeepers) the unique identifier of the Solutions Enabler instance installed on the SRM server should be retrieved.
This identifier can be obtained by opening up the Windows command prompt on the local server and executing the following command:
symacl -unique
Figure 184 shows a printout of this command where the unique identifier of the local install of Solutions Enabler is returned.
Figure 184. Retrieving the SYMACL unique identifier with Solutions Enabler
Symmetrix Access Control identifies individual management hosts with an access ID. There are two different approaches to generating access IDs:
Alternate access IDs are available for all platforms. Alternate access IDs do not utilize the host’s hardware identifiers (such as MAC address) to generate an encrypted access ID. When enabled, Solutions Enabler can:
<Solutions Enabler_HOME>/config/options
To activate an alternate access ID randomly:
symacl -unique -passphrase Passphrase
To activate an alternate access ID using a passphrase:
symacl -unique -passphrase Passphrase
To activate an alternate access ID using a passphrase stored in a file on the local disk:
symacl -unique -passphrase -file pathname
Anyone with access to PowerMax management software can execute functions on any PowerMax device. Many applications can issue management commands to any device in a PowerMax deployment.
Such shared systems may be vulnerable to a host (accidentally or intentionally) tampering with another’s devices. To prevent this, the symacl command can be used by to set up and restrict host access to defined sets of devices across the PowerMax arrays.
By default, client/server mode operations are executed on the server host using the access ID of the server. Access control checks are performed against the rules established for the server host, regardless of which client host initiated the operations.
Users can use the access ID of the client host instead of the server host. When this is enabled, access control rules must be established for, and checked against, the client hosts from which the operations are issued.
To use the access ID of the client host, users must make changes in the options file on the client and the server host, as explained in the following sections.
On the server host, the following option controls the source of the access ID used for the client/server sessions:
SYMAPI_USE_ACCESS_ID = CLIENT | SERVER | ANY
The behavior of this option is as follows:
The use of the alternate access ID, described earlier, must be enabled to use this functionality:
SYMAPI_ALTERNATE_ACCESS_ID = ENABLE
Additionally, users must set the following option to control whether the client can send its own access ID to the server for use there:
SYMAPI_CLIENT_SIDE_ACCESS_ID = ENABLE
The behavior of this option is as follows:
SYMACLs can be created and configured through the use of Unisphere for PowerMax, or Solutions Enabler command line utilities. The GUI is the preferred method for configuration as it offers a simple, wizard-based interface for setting up ACLs. Figure 185 shows how to access SYMACL configuration from within Unisphere for PowerMax.
Figure 185. Configuring SYMACLs with Unisphere for PowerMax
Note: Configuring SYMACLs requires the PIN created when the SYMACL database was initialized. This PIN, while customer provided, can only be set by Dell personnel when the database is created. For security reasons, this PIN cannot be changed or viewed with customer management tools such as Unisphere for PowerMax or Solutions Enabler CLI.
[56] For more information about the syntax of the symacl command, refer to the Dell Solutions Enabler CLI Command Reference.