Contents
About migration from KUMA
This section covers the migration from KUMA standalone to Kaspersky Next XDR Expert. Please note that the provided scenario refers to a situation, where you perform an initial Kaspersky Next XDR Expert installation along with the migration of existing KUMA standalone. If you already have a deployed instance of Kaspersky Next XDR Expert, you will not be able to migrate KUMA standalone with the respective data by following this scenario.
You must migrate data from KUMA 3.0.3. If you are using an earlier version, you have to update KUMA standalone up to 3.0.3, and then perform the migration to Kaspersky Next XDR Expert.
You can perform the migration for the following types of KUMA standalone deployment:
- Installation on a single server.
- Distributed installation.
- Distributed installation in a high availability configuration.
Migration implies two stages:
After you complete both stages, the transferred data and services are available. All services of KUMA standalone are configured for operating as a part of Kaspersky Next XDR Expert. Also, the transferred services are restarted.
What is transferred
- The /opt/kaspersky/kuma/core/data directory.
- The encryption key file /opt/kaspersky/kuma/core/encryption/key.
- The MongoDB base backup.
- Hierarchy of Kaspersky Security Center administration servers.
The administration servers that migrate to Kaspersky Next XDR Expert become bound to its root Administration Servers.
- Tenants.
The migrated tenants are registered in Kaspersky Next XDR Expert and become a child of the Root tenant. Each tenant belongs to an administration group in Kaspersky Next XDR Expert.
To migrate Kaspersky Security Center Administration Servers, domain users, and their roles, create a configuration file, and then set necessary parameters in this file.
- Binding of tenants to Kaspersky Security Center Administration Servers.
The secondary administration server of Kaspersky Security Center is registered in the corresponding service of the tenant settings of Kaspersky Security Center.
A link between a tenant and an Administration Server remains the same as it was in KUMA.
You can bind tenants only to physical Administration Servers. Binding tenants to virtual Administration servers is unavailable.
- Domain users.
For each domain with which the KUMA integration is configured, and which users have assigned roles in KUMA tenants, you must run domain controller polling by using Administration Server.
- Roles.
After domain controller polling is finished and the domain users are migrated, these users are assigned XDR roles in Kaspersky Next XDR Expert and the right to connect to Kaspersky Security Center.
If the migrated users had the assigned roles in secondary administration server of Kaspersky Security Center, you have to assign to these users the same roles in the administration group of its root Administration Server.
If you manually assigned XDR roles and/or Kaspersky Security Center roles to the users before running the migrator, after migration is finished, the users are assigned new XDR roles in the tenant specified in the configuration file and the manually assigned XDR roles are deleted. Kaspersky Security Center roles are not overwritten.
- Integration with Kaspersky Security Center.
- Integration with LDAP and third-party systems remain available.
- Events.
- Assets.
- Resources.
- Active services
What is not transferred
- Alerts and incidents are not be available in Kaspersky Next XDR Expert after migration. If you want to have original alerts and incidents at hand, we recommend that you restore KUMA backup on an individual host. This way, you will be able to perform a retrospective scanning.
- Dashboards are not transferred and remain available only in KUMA standalone in the read only mode, you will not be able to go over to the related alerts.
Integration with Active Directory (AD) and Active Directory Federation Services (ADFS).
Migrating KUMA standalone to Kaspersky Next XDR Expert
To perform the migration from KUMA standalone to Kaspersky Next XDR Expert, complete the following stages.
Preparation
Before you perform the migration, follow the preliminary steps:
- Copy the CA certificate from KUMA Core standalone to the Administrator's host.
- Generate a new token and keep the token in a safe place. Later, you will specify the new token in the smp_param file.
- Prepare a backup for KUMA standalone and keep the backup in a safe place. In case of a force majeure, you will be able to restore the instance of KUMA standalone and repeat the migration all over again. Otherwise, in case of a failure, KUMA Core may be corrupted and you will not be able to perform the migration.
Also, we recommend that you keep track of time when preparing the backup, and notice the size of the backup. Later, you may need to adjust the respective values for timeout and spare space on the storage volume in the smp_param file.
- Prepare the hosts for installation of Kaspersky Next XDR Expert: verify that you opened the required ports, copied the CA certificate from KUMA Core to the Administrator’s host, generated the token, that you have SSH root access to the target hosts of KUMA standalone and access from Kaspersky Next XDR Expert workers to port TCP 7223 of the deployed KUMA standalone.
- Prepare the inventory file. In the inventory file, list all hosts that you use for services in KUMA standalone. The hosts must match in both inventory files. If necessary, you can get the required information regarding hosts in KUMA Resources → Active services. Please note that you should specify both FQDN and IP-address for all hosts.
- Prepare the smp_param file. Ensure that you set the following parametes:
- Set the migration flag to true.
- name: migration
source:
value: "true"
- Specify the path to the CA certificate that you copied from KUMA standalone to the Administrator’s host.
- name: coreSourceCA
source:
path: "<full path to the CA certificate>"
- Specify FQDN for KUMA Core standalone.
- name: coreSourceFQDN
source:
value: "<KUMA Core standalone FQDN>”
- Specify the token.
- name: coreSourceToken
source:
value: <token>
- Specify the helm timeout.
The default value of the
helmTimeout
parameter is 5 minutes. If copying backup takes longer than the specified timeout value, an error may occur. As a result, KUMA resources may become unavailable. To avoid such scenario, keep track of time when preparing the backup and adjust the timeout value accordingly. In the following example, the timeout is set to 50 minutes.- name: helmTimeout
source:
value: "50m0s"
- Specify custom settings for storage volume.
If you plan to import a large MongoDB base, ensure that the
LowResource
parameter value is set tofalse
.- name: lowResources
source:
value: 'false'
Also, please specify the required size of the volume in accordance with the size of a prepared backup. The default size value is 512 GB which may be excessive for your deployment. Adjust the value as applicable and specify the required values. In the following example, the volume for KUMA Core is set to 50 GB:
- name: coreDiskRequest
source:
value: 50Gi
- Set the migration flag to true.
Migration
Run the KDT utility using the prepared smp_param file, same as for initial installation.
After migration is complete, all services are available in KUMA console under Resources → Active services.
Troubleshooting
If the migration fails, follow the steps:
- Go to the directory, where the KDT utility is located and run the following command to check the log file:
./kdt status -l kuma
If you figure out that the migration failed when installing the services, which would be clear of the log records, the other steps of this procedure would be of no help and we recommend that you contact the Customer support service.
- Check the parameters in the smp_param file. Verify that the required ports are open and the target hosts are available, and that you set appropriate value for the helmTimeout parameter. If necessary, export the smp_param file and amend the values as applicable:
./kdt ec > /root/ksmp/smp_param1.yaml
- Run the kdt tool with the edited smp_param file:
./kdt apply --force -k <KUMA as a part of XDR archive>.tar -i /root/ksmp/smp_param1.yaml
Running the migrator to transfer data
After migration from KUMA standalone is complete, you have to run the migrator to transfer data.
You can obtain the migrator through Technical Support.
To transfer Kaspersky Security Center Administration Servers, domain users, and assigned roles:
- Run the installation of KUMA migrator in the command line.
kdt apply --force -k kuma-migrator_
<version>
.tar --accept-eula
- Fetch the data for migration by running the following command:
kdt invoke kuma-migrator --action fetch
- Copy the result of the data fetch, and then create a configuration file in the YAML format.
- Open the configuration file and insert the result of the data fetch.
If necessary, you can delete Kaspersky Security Center Administration Servers or users that you do not want to migrate.
- For Kaspersky Security Center Administration Servers, specify information in the following fields:
Login
.Password
.URL
. You have to specify the full path by adding https://.Thumbprint_sha1_encoded
. You have to specify the SHA-1 thumbprint of the Kaspersky Security Center Server certificate.You can get the Administration Server certificate in OSMP Console. To do this, in the main menu, click the settings icon (
) next to the name of the required Administration Server, and then on the General tab click the View Administration Server certificate link to download the certificate.
Insecure_skip_verify
.The
false
value is selected for this parameter by default. In this case, the Administration Server certificate is verified when performing the migration. If you want to disable certificate verification, you can specify thetrue
value in this field.We do not recommend that you disable certificate verification.
- Run the corresponding commands to migrate data.
If you want to migrate all data, run the following command:
kdt invoke kuma-migrator --action migrate-all --param migrationConfigFilePath=
<configuration file name>
.yaml
If you want to migrate only Kaspersky Security Center Administration Servers, run the following command:
kdt invoke kuma-migrator --action migrate-ksc-servers --param migrationConfigFilePath=
<configuration file name>
.yaml
If you want to migrate only users, run the following command:
kdt invoke kuma-migrator --action migrate-users --param migrationConfigFilePath=
<configuration file name>
.yaml