Migration Summary

This section provides a summary of the CTE resources migrated from the DSM to CipherTrust Manager, mapping of the resources that are handled differently between the two key managers. Also, the section provides any constraints applicable to the migrated resources and describes how to interpret the migration status.

Resource Mapping

This table describes how the DSM resources are mapped with resources on the CipherTrust Manager after migration.

Migration Workflow and Exceptions/Deviations

Host | Client

Migration Workflow

• All related parameters configured on the DSM will be migrated as is to the CipherTrust Manager.

• Only the FS type hosts will be migrated to the CipherTrust Manager. Other host types, for example, VDE and Key, will NOT be migrated.

• After migration, every client needs to be registered with the CipherTrust Manager to receive its configuration.

Exceptions/Deviations

• Hosts marked for deletion on the DSM will NOT be migrated to the CipherTrust Manager.

Host Group | Client Group

Migration Workflow

• All related parameters (except the client group password) configured on the DSM will be migrated as is to the CipherTrust Manager.

• Host groups of only HDFS and NON-CLUSTER types will be migrated.

Exceptions/Deviations

• All host groups will be migrated with an auto-generated password (required for Challenge Response). Hosts with manual passwords configured on the DSM will also be migrated, but with a new auto generated password on the CipherTrust Manager. Manual password migration will be supported in a future CipherTrust Manager release.

  If required, auto generated password could be changed to manual mode on the CipherTrust Manager interfaces after migration.

• Host groups' HDFS configurations for browsing HDFS nodes will NOT be migrated. The CipherTrust Manager does not support browsing of resource sets.

Host Group Association | Client Group - Client Association

Migration Workflow

All successfully migrated host will be migrated as members to the successfully migrated host groups according to the DSM configuration.

Exceptions/Deviations

• Configurations of hosts or host groups that could not be migrated due to any reason will NOT be migrated.

• GuardPoints of host groups will NOT be migrated as part of the migration activity. All GuardPoints of a host group will be automatically propagated in the background after successful association.

User Sets | User Sets

Migration Workflow

• All related parameters configured on the DSM will be migrated as is to the CipherTrust Manager.

Exceptions/Deviations

• Not applicable

Resource Sets | Resource Sets

Migration Workflow

• All related parameters configured on the DSM will be migrated as is to the CipherTrust Manager.

Exceptions/Deviations

• Not applicable

Process Sets | Process Sets

Migration Workflow

• All related parameters configured on the DSM will be migrated as is to the CipherTrust Manager.

Exceptions/Deviations

• Not applicable

Signature Sets | Signature Sets

Migration Workflow

• All related parameters configured on the DSM will be migrated as is to the CipherTrust Manager.

• All the associated signatures under each signature set will be migrated to the CipherTrust Manager.

• Signature sets will retain their last signing state on the DSM on the CipherTrust Manager after migration.

Exceptions/Deviations

• Not applicable

Policy | Policy

Migration Workflow

• All related parameters configured on the DSM will be migrated as is to the CipherTrust Manager.

• All policy elements, that is, security rules, key rules, data transformation rules, LDT rules, and IDT rules will be migrated as is to the CipherTrust Manager.

Exceptions/Deviations

• Policies will be migrated with version 0 to the CipherTrust Manager irrespective of their versions on the DSM.

• Policy audit records on the DSM will NOT be migrated to the CipherTrust Manager.

Logging, QoS, and Syslog configuration | Profile

Migration Workflow

• Logging, QoS, and Syslog configuration on the DSM will be migrated as a joint resource under profiles on the CipherTrust Manager. Profiles will be associated with the clients and client groups based on the DSM configuration. Every client or client group will have the same configuration for these resources/parameters. However, they will be controlled through a single resource called profile on the CipherTrust Manager.

• All the host/host groups having the same configuration on the DSM will be associated with the same profile on the CipherTrust Manager.

• After migration, clients and client groups can be associated with different profiles or the existing profile can be modified appropriately.

• After migration, any modifications in profiles will affect all the clients and client groups linked with the profile.

Exceptions/Deviations

• Syslog configuration used only for the CTE agents will be migrated. Syslog configuration used by the DSM for its log upload will NOT be migrated.

• If migration of these configurations fails due to any reason (for example, invalid TLS configuration on the DSM), the default profile will be associated with the migrated hosts and host groups.

GuardPoints | GuardPoints

Migration Workflow

• Client GuardPoints

  • All related parameters configured on the DSM will be migrated as is to the CipherTrust Manager.

• ClientGroup GuardPoints

  • All valid GuardPoints under a host group will be migrated as is to the CipherTrust Manager.

Exceptions/Deviations

• Efficient Storage GuardPoints (ESG) will NOT be migrated.

• ClientGroup GuardPoints

  GuardPoints having invalid configuration that might be created due to limited restrictions on the DSM will either be modified before migration or dropped from the migration, as described below.

  • GuardPoints with Secure Start enabled on non-Windows paths will NOT be migrated.

  • GuardPoints with Transform Sparse Region enabled with a non-LDT policy will be modified by disabling Sparse Region and then migrated with rest of the configuration intact.

  • GuardPoints with Automount enabled on Windows path will be modified by disabling Automount and then migrated with rest of the configuration intact.

• ClientGroup - Client Association GuardPoints

  • Client group GuardPoints that are propagated to all member clients will NOT be migrated. They will be created in background after the association between the client groups and clients is successfully migrated.

  • Any modifications made to such GuardPoints on the DSM after their propagation on the client, will NOT be available after migration. GuardPoints with the configuration available under the client group will be propagated as is on the CipherTrust Manager.

Important Notes on Migration

• Hosts marked for deletion on the DSM will NOT be migrated to the CipherTrust Manager.

• All host groups will be migrated with an auto-generated password.

• GuardPoints of host groups will NOT be migrated as part of the migration activity. All GuardPoints of a host group will be automatically propagated in the background after successful association.

  Any modifications made to host group GuardPoints on the DSM on the client level after their propagation on the client, will NOT be available after migration. GuardPoints with the configuration available under the client group will be propagated as is on the CipherTrust Manager.

  For example, a host group GuardPoint HG_GP1 is enabled under a host group and propagated to the host. Later this GuardPoint is disabled on the host on the DSM. After that, if such data is migrated to the CipherTrust Manager, the corresponding GuardPoint will be created as an enabled GuardPoint on the client group and client on the CipherTrust Manager. The GuardPoint is enabled at the client group level, so the GuardPoint is propagated accordingly.

• Policies will be migrated with version 0. Policy audit records will NOT be migrated.

• Time Sets will NOT be migrated. They are not supported on the CipherTrust Manager.

• Syslog configuration used only for CTE agents, will only be migrated, syslog configuration used by DSM for its log upload will NOT be migrated.

• Syslog configuration used only for the CTE agents will be migrated. Syslog configuration used by the DSM for its log upload will NOT be migrated.

• Efficient Storage and CIFS GuardPoints will NOT be migrated.

• GuardPoints with Secure Start enabled on non-Windows paths will NOT be migrated.

Interpreting Migration Status

After you have triggered the migration, you can track its progress by running the ksctl migration status command. This command returns the overview of all the migrated resources classified in multiple categories, for example, Number of Processed, Number of Ignored, and Number of Failed (Error) with the high-level reasons why a particular resource is ignored or failed during the migration process.

./ksctl migrations status

{
    "id": "06d3efbe-590b-4e55-ace5-96e9ba486246",
    "overall_status": "Failed",
    "source": "DSM",
    "keys_status": {
        "status": "Completed",
        "num_processed": 0,
        "num_failed": 0,
        "num_ignored": 2,
        "error_details": [
            "Key uniquetohost exists for version 0, ignoring it",
            "Key uniquetohost_auto exists for version 0, ignoring it",
        ]
    },
    "keys_links_status": {
        "status": "",
        "num_processed": 0,
        "num_failed": 0,
        "num_ignored": 0
    },
    "domains_status": {
        "status": "Completed",
        "num_processed": 0,
        "num_failed": 0,
        "num_ignored": 1,
        "error_details": [
            "Domain dom1 already exists, not recreating it",
        ]
    },
    "cte_client_status": {
        "status": "Completed",
        "num_processed": 10,
        "num_failed": 0,
        "num_ignored": 2,
        "ignore_details": [
            "CTE Client keyagent-one migration Skipped. Reason: Only FS agent Hosts to be migrated. Skipping Host: keyagent-one",
            "CTE Client 10.164.15.216 already exists, not recreating it",
            ]
    },
    ...
    ...
    ...
    "cte_guard_point_status": {
        "status": "Failed",
        "num_processed": 34,
        "num_failed": 1,
        "num_ignored": 2,
        "error_details": [
            "failed to create CTE GuardPoint /test-1/ Err: Server error [16/NCERRResourceNotFound: Resource not found]: . HTTP code:404: 404 Not Found",
        ],
        "ignore_details": [
            "CTE GuardPoint https://s3.amazonaws.com/amithenrytestbucket6;https://s3.amazonaws.com/amithenrytestbucket777 already exists, not recreating it",
            "CTE GuardPoint E:\\my_test_1\\ already exists, not recreating it",
            ]
        },
    "cte_client_domain_sharing_status":{
        "status": "Completed",
        "num_processed": 1,
        "num_failed": 0,
        "num_ignored": 0
    },
    "cte_client_group_domain_sharing_status": {
        "status": "Completed",
        "num_processed": 1,
        "num_failed": 0,
        "num_ignored": 0
    }
}

Important Notes on Migration Status

• The error_details and ignore_details parameters provide the high-level information about the reason of failure or skipping the resource from migration. For detailed information, review the CipherTrust Manager logs and audit records (for each domain).

• For resources such as GuardPoint, the number shown in the status will NOT include the client group-client association GuardPoints available in the backup. They are created in the background after successful association of clients and client groups.

• Status shown as Failed indicates an error with the resources shown under num_failed. Other resources with no issues under the same category are successfully processed and are not affected with overall status as failed.

  For example, GuardPoints of hosts marked for deletion are not migrated and end up in the error section, as the linked host is not migrated itself. It leads to the overall status as failed for the GuardPoint migration, but all other GuardPoints under num_processed are successfully migrated.

• CTE reports offer a better alternative to verify the resources migrated from the DSM.