PlateSpin Migrate’s user authorization and authentication mechanism is based on user roles, and controls application access and operations that users can perform. The mechanism is based on Integrated Windows Authentication (IWA) and its interaction with Internet Information Services (IIS).
NOTE:If you have installed a PlateSpin Migrate Server localized for one language and a PlateSpin Migrate Client localized for a different language, do not use authorization credentials that include any language-specific characters. Using such characters in the login credentials causes miscommunication between the client and the server: the credentials are rejected as invalid.
PlateSpin Migrate’s user auditing functionality is provided through the capability to log user actions (see Setting Up User Activity Logging).
A PlateSpin Migrate role is a collection of PlateSpin Migrate privileges that entitle a particular user to perform specific actions. During installation, the PlateSpin Migrate installation program creates three local Windows groups on the PlateSpin Server host: PlateSpin Migrate Administrators, PlateSpin Migrate Power Users, and PlateSpin Migrate Operators. These groups map directly to the three PlateSpin Migrate roles that control user authorization and authentication:
Group for PlateSpin Migrate Client Users |
Group for PlateSpin Migrate Web Interface Users |
Description |
---|---|---|
PlateSpin Administrators |
Workload Conversion Administrators |
Have unlimited access to all features and functions of the application. A local administrator is implicitly part of this group. |
PlateSpin Power Users |
Workload Conversion Power Users |
Have access to most features and functions of the application with some limitations, such as restrictions in the capability to modify system settings related to licensing and security. |
PlateSpin Operators |
Workload Conversion Operators |
Have access to a limited subset of system features and functions, sufficient to maintain day-to-day operation. |
When a user attempts to connect to a PlateSpin Server, the credentials provided through the PlateSpin Migrate Client are validated by IIS. If the user is not a member of one of the PlateSpin Migrate roles, connection is refused. If the user is a local administrator on the PlateSpin Server host, that account is implicitly regarded as a PlateSpin Migrate Administrator.
The Permission details for the PlateSpin Migrate roles depends on whether you use the PlateSpin Migrate Client or the PlateSpin Migrate Web Interface for migrating the workloads:
For information on PlateSpin Migrate Roles and permission details when you use PlateSpin Migrate Client to perform the workload migration, see Table 2-3.
For information on PlateSpin Migrate Roles and permission details when you use PlateSpin Migrate Web Interface to perform the workload migration, see Table 2-4.
Table 2-3 PlateSpin Migrate Roles and Permission Details For PlateSpin Migrate Client Users
Role Details |
Administrators |
Power Users |
Operators |
---|---|---|---|
Licensing: Add, delete licenses; transfer workload licenses |
Yes |
No |
No |
Machines: Discover, undiscover |
Yes |
Yes |
No |
Machines: Delete virtual machines |
Yes |
Yes |
No |
Machines: View, refresh, export |
Yes |
Yes |
Yes |
Machines: Import |
Yes |
Yes |
No |
Machines: Export |
Yes |
Yes |
Yes |
PlateSpin Migrate Networks: Add, delete |
Yes |
No |
No |
Jobs: Create new job |
Yes |
Yes |
No |
Jobs: View, abort, change start time |
Yes |
Yes |
Yes |
Imaging: View, start synchronization in existing contracts |
Yes |
Yes |
Yes |
Imaging: Consolidate increments, apply increments to base, delete increments, install/delete image servers |
Yes |
Yes |
No |
Block-Based Transfer Components: Install, upgrade, remove |
Yes |
Yes |
No |
Device Drivers: View |
Yes |
Yes |
Yes |
Device Drivers: Upload, delete |
Yes |
Yes |
No |
PlateSpin Server access: View Web services, download client software |
Yes |
Yes |
Yes |
PlateSpin Server settings: Edit settings that control user activity logging and SMTP notifications |
Yes |
No |
No |
PlateSpin Server settings: Edit all server settings except those that control user activity logging and SMTP notifications |
Yes |
Yes |
No |
Run Diagnostics: Generate detailed diagnostic reports on jobs. |
Yes |
Yes |
Yes |
Post-conversion Actions: Add, update, delete |
Yes |
Yes |
No |
Table 2-4 PlateSpin Migrate Roles and Permission Details For PlateSpin Migrate Web Interface Users
Role Details |
Administrators |
Power Users |
Operators |
---|---|---|---|
Add Workload |
Yes |
Yes |
No |
Remove Workload |
Yes |
Yes |
No |
Configure Migration |
Yes |
Yes |
No |
Prepare Migration |
Yes |
Yes |
No |
Run Full Replication |
Yes |
Yes |
Yes |
Run Incremental Replication |
Yes |
Yes |
Yes |
Pause/Resume Schedule |
Yes |
Yes |
Yes |
Test Cutover |
Yes |
Yes |
Yes |
Cutover |
Yes |
Yes |
Yes |
Abort |
Yes |
Yes |
Yes |
Settings (All) |
Yes |
No |
No |
Run Reports/Diagnostics |
Yes |
Yes |
Yes |
To allow specific Windows domain or local users to carry out specific PlateSpin Migrate operations according to designated role, add the required Windows domain or user account to the applicable Windows local group (PlateSpin Administrators, PlateSpin Power Users, or PlateSpin Operators) on the PlateSpin Server host. For more information, see your Windows documentation.
PlateSpin Migrate includes unique user roles (and a tool for creating them in a VMware datacenter) that make it possible non-administrative VMware users (or “enabled users”) to perform Migrate lifecycle operations in the VMware environment. These roles makes it possible for you, as a service provider, to segment your VMware cluster to allow multitenancy: where multiple Migrate containers are instantiated in your datacenter to accommodate Migrate customers or “tenants” who want to keep their data and evidence of their existence separate from and inaccessible to other customers who also use your datacenter.
This section includes the following information:
PlateSpin Migrate requires certain privileges to access and perform tasks in the VMware Infrastructure (that is, VMware “containers”), making the Migrate workflow and functionality possible in that environment. Because there are many of these required privileges, NetIQ has created a file that defines the minimum required privileges and aggregates them respectively into three VMware custom roles:
PlateSpin Virtual Machine Manager
PlateSpin Infrastructure Manager
PlateSpin User
This definition file, PlateSpinRole.xml, is included in the PlateSpin Migrate Server installation. An accompanying executable, PlateSpin.VMwareRoleTool.exe,accesses the file to enable the creation of these custom PlateSpin roles in a target vCenter environment.
This section includes the following information:
From the location where the role tool was installed, run the tool from the command line, using this basic syntax:
PlateSpin.VMwareRoleTool.exe /host=[host name/IP] /user=[user name] /role=[the role definition file name and location] /create
NOTE:By default, the role definition file is located in the same folder with the role definition tool.
Apply the following parameters as needed when you use PlateSpin.VMwareRoleTool.exe to create or update roles in vCenter:
/create |
(mandatory) Creates the roles defined by the /role parameter |
/get_all_privileges |
Display all server-defined privileges |
|
|
Optional Flags |
|
/interactive |
Run the tool with interactive options that allow you to choose to create individual roles, check role compatibility, or list all compatible roles. |
/password=[password] |
Provide the VMware password (bypasses the password prompt) |
/verbose |
Display detailed information |
Usage: PlateSpin.VMwareRoleTool.exe /host=houston_sales /user=pedrom /role=PlateSpinRole.xml /create
Resulting Actions:
The role definition tool runs on the houston_sales vCenter server, which has an administrator with the user name pedrom.
In the absence of the /password parameter, the tool prompts for the user password, which you enter.
The tool accesses the role definition file, PlateSpinRole.xml, which is located in the same directory as the tool executable (there was no need to further define its path).
The tool locates the definition file and is instructed (/create) to create the roles defined in the contents of that file in the vCenter environment.
The tool accesses the definition file and creates the new roles (including the appropriate minimum privileges for defined, limited access) inside vCenter.
The new custom roles are to be assigned to users later in vCenter.
You use the vCenter client to manually create and assign the PlateSpin custom roles. This requires creating the roles with the enumerated privileges as defined in PlateSpinRole.xml. When you create manually, there is no restriction on the name of the role. The only restriction is that the role names you create as equivalents to those in the definition file have all of the appropriate minimum privileges from the definition file.
For more information about how to create custom roles in vCenter, see Managing VMWare VirtualCenter Roles and Permissions in the VMware Technical Resource Center.
As you set up a multitenancy environment, you need to provision a single Migrate server per customer or “tenant.” You assign this Migrate server an enabled user with special Migrate VMware roles. This enabled user creates the Migrate container. As service provider, you maintain this user’s credentials and do not disclose them to your tenant customer.
The following table lists the roles you need to define for the enabled user. It also includes more information about the purpose of the role:
vCenter Container for Role Assignment |
Role Assignment Specifics |
Propagate Instructions |
More Information |
---|---|---|---|
Root of vCenter inventory tree. |
Assign the enabled user the PlateSpin Infrastructure Manager (or equivalent) role. |
For security reasons, define the permission as non-propagating. |
This role is needed to monitor tasks being performed by the Migrate software and to end any stale VMware sessions. |
All datacenter objects where the enabled user needs access |
Assign the enabled user the PlateSpin Infrastructure Manager (or equivalent) role. |
For security reasons, define the permission as non-propagating. |
This role is needed to allow access to the datacenter’s datastores for file upload/download. Define the permission as non-propagating. |
Each cluster to be added to Migrate as a container, and each host contained in the cluster |
Assign the enabled user the PlateSpin Infrastructure Manager (or equivalent) role. |
Propagation is at the discretion of the VMware administrator. |
To assign to a host, propagate the permission from the cluster object or create an additional permission on each cluster host. If the role is assigned on the cluster object and is propagated, no further changes are necessary when you add a new host to the cluster. However, propagating this permission has security implications. |
Each Resource Pool where the enabled user needs access. |
Assign the enabled user the PlateSpin Virtual Machine Manager (or equivalent) role. |
Propagation is at the discretion of the VMware administrator. |
Although you can assign access to any number of Resource Pools in any location in the tree, you must assign the enabled user this role on at least one Resource Pool. |
Each VM folder where the enabled user needs access |
Assign the enabled user the PlateSpin Virtual Machine Manager (or equivalent) role. |
Propagation is at the discretion of the VMware administrator. |
Although you can assign access to any number of VM Folders in any location in the tree, you must assign the enabled user this role on at least one folder. |
Each Network where the enabled user needs access. Distributed Virtual Networks with a dvSwitch and a dvPortgroup |
Assign the enabled user the PlateSpin Virtual Machine Manager (or equivalent) role. |
Propagation is at the discretion of the VMware administrator. |
Although you can assign access to any number of networks in any location in the tree, you must assign the enabled user this role on at least one folder.
|
Each Datastore and Datastore Cluster where the enabled user needs access |
Assign the enabled user the PlateSpin Virtual Machine Manager (or equivalent) role. |
Propagation is at the discretion of the VMware administrator. |
The enabled user must have been assigned this role on at least one Datastore or Datastore Cluster. For Datastore Clusters, the permission must be propagated to the contained datastores. Not providing access to an individual member of the cluster causes both prepare and full replications to fail |
The following table shows the role you can assign to the customer or tenant user.
vCenter Container for Role Assignment |
Role Assignment Specifics |
Propagate Instructions |
More Information |
---|---|---|---|
Each resource pool(s) and folder(s) where the customer's VMs will be created. |
Assign the tenant user the PlateSpin User (or equivalent) role. |
Propagation is at the discretion of the VMware administrator. |
This tenant is a member of the PlateSpin Administrators group on the PlateSpin Migrate server and is also on the vCenter server. If the tenant will be granted the ability to change the resources used by the VM (that is, networks, ISO images, and so forth), grant this user the necessary permissions on those resources. For example, if want to you allow the customer to change the network where their VM is attached, this user should be assigned the Read-only role (or better) on all of the networks being made accessible to the customer. |
The figure below illustrates a Virtual Infrastructure in the vCenter console. The objects labeled in blue are assigned the Infrastructure Manager role. The objects labeled in green are assigned the Virtual Machine Manager role. The tree does not show VM folders, Networks and Datastores. Those objects are assigned the PlateSpin Virtual Machine Manager role.
Figure 2-3 Roles assigned in vCenter
PlateSpin software uses an enabled user only to perform protection lifecycle operations. From your perspective as a service provider, an end user never has access to the enabled user’s credentials and is unable to access the same set of VMware resources. In an environment where multiple Migrate servers are configured to use the same vCenter environment, Migrate prevents possibilities for cross-client access. The major security implications include:
With the PlateSpin Infrastructure Manager role assigned to the vCenter object, every enabled user can see (but not affect) the tasks performed by every other user.
Because there is no way to set permissions on datastore folders/subfolders, all enabled users with permissions on a datastore have access to all other enabled users’ disks stored on that datastore.
With the PlateSpin Infrastructure Manager role assigned to the cluster object, every enabled user is able to turn off/on HA or DRS on the entire cluster
With the PlateSpin User role assigned at the storage cluster object, every enabled user is able to turn off/on SDRS for the entire cluster
Setting the PlateSpin Infrastructure Manager Role on the DRS Cluster object and propagating this role allows the enabled user to see all VMs placed in the default resource pool and/or default VM folder. Also, propagation requires the administrator to explicitly set the enabled user to have a “no-access” role on every resource pool/VM folder that he or she should not have access to.
Setting the PlateSpin Infrastructure Manager Role on the vCenter object allows the enabled user to end sessions of any other user connected to the vCenter.
NOTE:Remember, in these scenarios, different enabled users are actually different instances of the PlateSpin software.
By default, PlateSpin Migrate records all user activities in a log file, PlateSpin.UserActivityLogging.log, located on your PlateSpin Server host, in the following directory:
..\PlateSpin Migrate Server\logs.
The format of an individual log entry is:
date|Category|description|user|details1|details2
The Category element describes the functional area applicable to a particular action, such as Security, Inventory (discovery operations), LicenseManagement, or Migration (workload portability operations).
Elements details1 and details2 depend on the Category and provide additional information if applicable.
Below is an example of a log entry recording the login action of a user with the domain account MyDomain\John.Smith.
2008-09-02 14:14:47|Security|User logged in|MyDomain\John.Smith
When the size of a log file reaches a specified value, it is rolled over to a new file with a sequential number appended to the name:
PlateSpin.UserActivityLogging.log.1 PlateSpin.UserActivityLogging.log.2 PlateSpin.UserActivityLogging.log.3
When the number of log files reaches a specified value, the system starts overwriting the oldest file each time a rollover is performed.
To enable or disable user activity logging, and to specify log file size and rollover options:
In the PlateSpin Migrate Client, click Tools > Options.
Click the Logging tab.
Specify the required options, then click OK.