2.2 Setting Up User Authorization and Authentication

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).

2.2.1 PlateSpin Migrate Roles

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

2.2.2 Assigning PlateSpin Migrate Roles to Windows Users

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.

2.2.3 Setting Up PlateSpin Migrate Multitenancy on VMware

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:

Using Tools to Define VMware Roles

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:

Basic Command Line Syntax

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.

Additional Command Line Parameters and Flags

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

Tool Usage Example

Usage: PlateSpin.VMwareRoleTool.exe /host=houston_sales /user=pedrom /role=PlateSpinRole.xml /create

Resulting Actions:

  1. The role definition tool runs on the houston_sales vCenter server, which has an administrator with the user name pedrom.

  2. In the absence of the /password parameter, the tool prompts for the user password, which you enter.

  3. 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).

  4. 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.

  5. 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.

(Option) Manually Defining the PlateSpin Roles 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.

Assigning Roles In vCenter

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.

  • To assign the correct role to the dvSwitch, propagate the role on the Datacenter (resulting in an additional object receiving the role) or place the dvSwitch in a folder and assign the role on that folder.

  • For a standard portgroup to be listed as an available network in the Migrate UI, create a definition for it on every host in the cluster.

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

Security Implications of Assigning VMware Roles

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.

2.2.4 Setting Up User Activity Logging

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:

  1. In the PlateSpin Migrate Client, click Tools > Options.

  2. Click the Logging tab.

  3. Specify the required options, then click OK.