9.2 Security and Ownership

Moving to a managed storage environment presents an opportunity to refine the security on the data itself. By defining the security that should be on the file system as a part of the policy, you are assured that the security of the data on the target network is in line with the security and governance requirements that your organization wants to employ. This can also contribute to present and future compliance requirements for your organization. Avoiding these types of exposure is another benefit of moving to a managed storage environment.

However, in many environments, there is a desire to migrate security and ownership assignments directly from the source environment to the target. This capability is accomplished through the creation and optional usage of an Identity Map as a part of a migration operation.

9.2.1 Defining an Identity Map for Security and Ownership Migration

For security and ownership information to be migrated between environments, the Cross-Empire Data Migration subsystem requires a series of object equivalence definitions to identify an object in the source environment as equivalent to an analogous object in the target environment. In other words, if an object in the source environment is given rights to a file or folder, and you want that trustee assignment to be migrated along with the data, then Novell Storage Manager must be told which object in the target environment is equivalent to it so that the appropriate rights assignment can be made. An identity map is a construct for creating and managing these equivalence definitions.

You can create and populate an identity map within the Cross-Empire Data Migration subsystem of the NSMAdmin interface. There are various options for automatically locating and matching objects based on a number of matching rules. There are options for creating manual assignments as well as for editing assignments.

However, some objects that are assigned rights in the source environment might not have an analogous object that already exists in the target environment. These objects need to be created before they can be defined to an identity map.

In addition, an analogous object might exist in the target environment, but might not be able to be assigned as a trustee, such as a container that is given rights in the source environment. The same container might exist in the target environment (Active Directory), but Active Directory does not support the assignment of a container as a security object. In these instances, a group representing the container is usually created for rights assignments.

You can import data into an identity map. This can be useful when you already have a data set defining equivalences, or you can easily create one using data from an external system.

In general, it is standard practice to iteratively evolve an identity map as needed to perform a migration. Within the interface, you can run a check scan against a given source file system path to check rights and ownership assignments against an identity map. This identifies which objects still need a definition within the map in order for a migration to finish with 100 percent coverage for security and ownership.

9.2.2 Using an Identity Map

When you are satisfied with the coverage within the identity map for a given file system path, you can use the identity map as a part of a migration. You can optionally use the identity map in conjunction with any migration operation type supported by the Cross-Empire Data Migration subsystem:

  • User storage migration

  • Collaborative or group storage migration

  • Direct folder storage migration

The system supports a single identity map within the framework at any one time. When the map is created or edited, the master copy is held by the NSM Engine and is automatically distributed to NSM Agents as necessary.

IMPORTANT:Certain operations during a Cross-Empire Data Migration involve building a cache on the local workstation or the NSM Engine. If the identity map contains more than 20,000 objects, the time it takes to cache all of the objects could significantly inhibit the speed of the migration.

Once the cache has been built the first time on the workstation or NSM Engine, it does not have to be rebuilt again.