Configuring Administration Server

This section describes the configuration process and properties of Kaspersky Security Center Administration Server.

Configuring the connection of OSMP Console to Administration Server

To set the connection ports of Administration Server:

1. In the main menu, click the settings icon () next to the name of the required Administration Server.

   The Administration Server properties window opens.

2. On the General tab, select the Connection ports section.

The application displays the main connection settings of the selected server.

Configuring internet access settings

Expand all | Collapse all

An internet connection is required for proper operation of Kaspersky Next XDR Expert components and can be used for specific integrations, both Kaspersky and third-party. For example, you must configure internet access for Administration Server to use Kaspersky Security Network and to download updates of anti-virus databases for Open Single Management Platform and managed Kaspersky applications.

The integration settings of some Kaspersky applications contain an option to enable or disable the usage of proxy server. For example, such an option is available when you configure integration with Kaspersky Threat Intelligence Portal.

To specify the internet access settings:

1. In the main menu, click the settings icon () next to the Administration Server name.

   The Administration Server properties window opens.

2. On the General tab, select the Configuring internet access section.
3. Enable the Use proxy server option if you want to use a proxy server when connecting to the internet. If this option is enabled, the fields are available for entering settings. Specify the following settings for a proxy server connection:
   • Address

     Address of the proxy server used for Open Single Management Platform connection to the internet.

   • Port number

     Number of the port through which Open Single Management Platform proxy connection will be established.

   • Bypass proxy server for local addresses

     No proxy server will be used to connect to devices in the local network.

   • Proxy server authentication

     If this check box is selected, in the entry fields you can specify the credentials for proxy server authentication.

     This entry field is available if the Use proxy server check box is selected.

   • User name

     User account under which connection to the proxy server is established (this field is available if the Proxy server authentication check box is selected).

   • Password

     Password set by the user under whose account the proxy server connection is established (this field is available if the Proxy server authentication check box is selected).

     To see the entered password, click and hold the Show button for as long as you require.

Certificates for work with Open Single Management Platform

This section contains information about Open Single Management Platform certificates and describes how to issue and replace certificates for OSMP Console and how to renew a certificate for Administration Server if the Server interacts with OSMP Console.

About Open Single Management Platform certificates

Open Single Management Platform uses the following types of certificates to enable a secure interaction between the application components:

• Administration Server certificate
• OSMP Console Server certificate
• OSMP Console certificate

By default, Open Single Management Platform uses self-signed certificates (that is, issued by Open Single Management Platform itself), but you can replace them with custom certificates to better meet the requirements of your organization's network and comply with the security standards. After Administration Server verifies whether a custom certificate meets all applicable requirements, this certificate assumes the same functional scope as a self-signed certificate. The only difference is that a custom certificate is not reissued automatically upon expiration. You replace certificates with custom ones by means of the klsetsrvcert utility or through the Administration Server properties section in OSMP Console, depending on the certificate type. When you use the klsetsrvcert utility, you need to specify a certificate type by using one of the following values:

• C—Common certificate for ports 13000 and 13291.
• CR—Common reserve certificate for ports 13000 and 13291.

The maximum validity period for any of the Administration Server certificates must be 397 days or less.

Administration Server certificates

An Administration Server certificate is required for the following purposes:

• Authentication of Administration Server when connecting to OSMP Console
• Secure interaction between Administration Server and Network Agent on managed devices
• Authentication when the primary Administration Servers are connected to secondary Administration Servers

The Administration Server certificate is created automatically during installation of the Administration Server component and it is stored in the /var/opt/kaspersky/klnagent_srv/1093/cert/ folder. You specify the Administration Server certificate when you create a response file to install OSMP Console. This certificate is called common ("C").

The Administration Server certificate is valid for 397 days. Open Single Management Platform automatically generates a common reserve ("CR") certificate 90 days before the expiration of the common certificate. The common reserve certificate is subsequently used for seamless replacement of the Administration Server certificate. When the common certificate is about to expire, the common reserve certificate is used to maintain the connection with Network Agent instances installed on managed devices. With this purpose, the common reserve certificate automatically becomes the new common certificate 24 hours before the old common certificate expires.

The maximum validity period for any of the Administration Server certificates must be 397 days or less.

If necessary, you can assign a custom certificate for the Administration Server. For example, this may be necessary for better integration with the existing PKI of your enterprise or for custom configuration of the certificate fields. When replacing the certificate, all Network Agents that were previously connected to Administration Server through SSL will lose their connection and will return "Administration Server authentication error." To eliminate this error, you will have to restore the connection after the certificate replacement.

If the Administration Server certificate is lost, you must reinstall the Administration Server component, and then restore the data in order to recover it.

You can also back up the Administration Server certificate separately from other Administration Server settings in order to move Administration Server from one device to another without data loss.

Mobile certificates

A mobile certificate ("M") is required for authentication of the Administration Server on mobile devices. You specify the mobile certificate in the Administration Server properties.

Also, a mobile reserve ("MR") certificate exists: it is used for seamless replacement of the mobile certificate. Open Single Management Platform automatically generates this certificate 60 days before the expiration of the common certificate. When the mobile certificate is about to expire, the mobile reserve certificate is used to maintain the connection with Network Agent instances installed on managed mobile devices. With this purpose, the mobile reserve certificate automatically becomes the new mobile certificate 24 hours before the old mobile certificate expires.

If the connection scenario requires the use of a client certificate on mobile devices (connection involving two-way SSL authentication), you can generate those certificates by means of the certificate authority for auto-generated user certificates ("MCA"). Also, in the Administration Server properties, you can specify custom client certificates issued by a different certification authority, while integration with the domain Public Key Infrastructure (PKI) of your organization enables you to issue client certificates by means of your domain certification authority.

Web Server certificate

Web Server, a component of Kaspersky Security Center Administration Server, uses a special type of certificate. This certificate is required for publishing Network Agent installation packages that you subsequently download to managed devices. For this purpose, Web Server can use various certificates.

Web Server uses one of the following certificates, in order of priority:

1. Custom Web Server certificate that you specified manually by means of OSMP Console
2. Common Administration Server certificate ("C")

OSMP Console certificate

The OSMP Console Server has its own certificate. When you open a website, a browser verifies whether your connection is trusted. The Web Console certificate allows you to authenticate the Web Console and is used to encrypt traffic between a browser and the Web Console.

When you open the Web Console, the browser may inform you that the connection to the OSMP Console is not private and the OSMP Console certificate is invalid. This warning appears because the OSMP Console certificate is self-signed and automatically generated by Open Single Management Platform. To remove this warning, you can do one of the following:

• Replace the Web Console certificate with a custom one (recommended option). Create a certificate that is trusted in your infrastructure and that meets the requirements for custom certificates.
• Add the Web Console certificate to the list of trusted browser certificates. We recommend that you use this option only if you cannot create a custom certificate.

Requirements for custom certificates used in Open Single Management Platform

The table below shows the requirements for custom certificates specified for different components of Open Single Management Platform.

Requirements for Open Single Management Platform certificates

Reissuing the certificate for OSMP Console

Most browsers impose a limit on the validity term of a certificate. To fall within this limit, the validity term of the OSMP Console certificate is limited to 397 days. You can replace an existing certificate received from a certification authority (CA) by issuing a new self-signed certificate manually. Alternatively, you can reissue your expired OSMP Console certificate.

Automatically reissuing the certificate for OSMP Console is not supported. You have to manually reissue the expired certificate.

When you open the OSMP Console, the browser may inform you that the connection to the OSMP Console is not private and the OSMP Console certificate is invalid. This warning appears because the OSMP Console certificate is self-signed and automatically generated by Open Single Management Platform. To remove or prevent this warning, you can do one of the following:

• Specify a custom certificate when you reissue it (recommended option). Create a certificate that is trusted in your infrastructure and that meets the requirements for custom certificates.
• Add the OSMP Console certificate to the list of trusted browser certificates after you reissue the certificate. We recommend that you use this option only if you cannot create a custom certificate.

To reissue the expired OSMP Console certificate:

Reinstall OSMP Console by performing one of the following:

• If you want to use the same installation file of OSMP Console, remove OSMP Console, and then install the same OSMP Console version.
• If you want to use an installation file of an upgraded version, run the upgrade command.

The OSMP Console certificate is reissued for another validity term of 397 days.

Replacing certificate for OSMP Console

By default, when you install OSMP Console Server (also referred to as OSMP Console), a browser certificate for the application is generated automatically. You can replace the automatically generated certificate with a custom one.

To replace the certificate for OSMP Console with a custom one:

1. Create a new response file required for the OSMP Console installation.
2. In this file, specify paths to the custom certificate file and the key file by using the certPath parameter and the keyPath parameter.
3. Reinstall OSMP Console by specifying the new response file. Do one of the following:
   • If you want to use the same installation file of OSMP Console, remove OSMP Console, and then install the same OSMP Console version.
   • If you want to use an installation file of an upgraded version, run the upgrade command.

OSMP Console works with the specified certificate.

Converting a PFX certificate to the PEM format

To use a PFX certificate in OSMP Console, you must first convert it to the PEM format by using any convenient OpenSSL-based cross-platform utility.

To convert a PFX certificate to the PEM format in the Linux operating system:

1. In an OpenSSL-based cross-platform utility, execute the following commands:

   openssl pkcs12 -in <filename.pfx> -clcerts -nokeys | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > server.crt

   openssl pkcs12 -in <filename.pfx> -nocerts -nodes | sed -ne '/-BEGIN PRIVATE KEY-/,/-END PRIVATE KEY-/p' > key.pem

2. Make sure that the certificate file and the private key are generated to the same directory where the .pfx file is stored.
3. OSMP Console does not support passphrase-protected certificates. Therefore, run the following command in an OpenSSL-based cross-platform utility to remove a passphrase from the .pem file:

   openssl rsa -in key.pem -out key-without-passphrase.pem

   Do not use the same name for the input and output .pem files.

   As a result, the new .pem file is unencrypted. You do not have to enter a passphrase to use it.

The .crt and .pem files are ready to use, so you can specify them in the OSMP Console installer.

Scenario: Specifying the custom Administration Server certificate

You can assign the custom Administration Server certificate, for example, for better integration with the existing public key infrastructure (PKI) of your enterprise or for custom configuration of the certificate fields. It is useful to replace the certificate immediately after installation of Administration Server.

The maximum validity period for any of the Administration Server certificates must be 397 days or less.

Prerequisites

The new certificate must be created in the PKCS#12 format (for example, by means of the organization's PKI) and must be issued by trusted certification authority (CA). Also, the new certificate must include the entire chain of trust and a private key, which must be stored in the file with the pfx or p12 extension. For the new certificate, the requirements listed below must be met.

Certificate type: Common certificate, common reserve certificate ("C", "CR")

Requirements:

• Minimum key length: 2048
• Basic constraints:
  • CA: true
  • Path Length Constraint: None

    Path Length Constraint value may be an integer different from "None" but not less than 1.

• Key Usage:
  • Digital signature
  • Certificate signing
  • Key encipherment
  • CRL Signing
• Extended Key Usage (EKU): server authentication and client authentication. The EKU is optional, but if your certificate contains it, the server and client authentication data must be specified in the EKU.

Certificates issued by a public CA do not have the certificate signing permission. To use such certificates, make sure that you installed Network Agent version 13 or later on distribution points or connection gateways in your network. Otherwise, you will not be able to use certificates without the signing permission.

Stages

Specifying the Administration Server certificate proceeds in stages:

1. Replacing the Administration Server certificate

   Use the command-line klsetsrvcert utility for this purpose.

2. Specifying a new certificate and restoring connection of Network Agents to the Administration Server

   When the certificate is replaced, all Network Agents that were previously connected to Administration Server through SSL lose their connection and return "Administration Server authentication error." To specify the new certificate and restore the connection, use the command-line klmover utility.

Results

When you finish the scenario, the Administration Server certificate is replaced and the server is authenticated by Network Agents on the managed devices.

Replacing the Administration Server certificate by using the klsetsrvcert utility

To replace the Administration Server certificate,

On the administrator host where the KDT utility is located, run the following command:

where:

• <path_to_new_certificate> is the path to the container with the certificate and a private key in the PKCS #12 format (file with the .P12 or .PFX extension).
• <password> is the password used for protection of the PKCS #12 container. The certificate and a private key are stored in the container, therefore, the password is required to decrypt the file with the container.

By default, certificate validation parameters are not specified, a custom certificate without signing permission is used. You can replace the common certificate for port 13000.

You do not need to download the klsetsrvcert utility. It is included in the Kubernetes cluster and is not available for direct running. You can run the klsetsrvcert utility only by using KDT from the administrator host.

Connecting Network Agents to Administration Server by using the klmover utility

After you replace the Administration Server certificate by using the command-line klsetsrvcert utility, you need to establish the SSL connection between Network Agents and Administration Server because the connection is broken.

To specify the new Administration Server certificate and restore the connection:

From the command line, run the following utility:

This utility is automatically copied to the Network Agent installation folder, when Network Agent is installed on a client device.

The description of the klmover utility parameters is presented in the table below.

Values of the klmover utility parameters

Hierarchy of Administration Servers

Some client companies, for example MSP, may run multiple Administration Servers. It can be inconvenient to administer several separate Administration Servers, so a hierarchy can be applied. Each Administration Server can have several secondary Administration Servers on different nesting levels of the hierarchy. The root Administration Server can only act as a primary Server.

In a hierarchy, a Linux-based Administration Server can work both as a primary Server and as a secondary Server. The primary Linux-based Server can manage both Linux-based and Windows-based secondary Servers. A primary Windows-based Server can manage a secondary Linux-based Server.

A "primary/secondary" configuration for two Administration Servers provides the following options:

• A secondary Administration Server inherits policies, tasks, user roles, and installation packages from the primary Administration Server, thus preventing duplication of settings.
• Selections of devices on the primary Administration Server can include devices from secondary Administration Servers.
• Reports and event selections on the primary Administration Server can contain data (including detailed information) from secondary Administration Servers.
• A primary Administration Server can be used as a source of updates for a secondary Administration Server.

The primary Administration Server only receives data from non-virtual secondary Administration Servers within the scope of the options listed above. This limitation does not apply to virtual Administration Servers, which share the database with their primary Administration Server.

Creating a hierarchy of Administration Servers: adding a secondary Administration Server

Expand all | Collapse all

In a hierarchy, a Linux-based Administration Server can work both as a primary Server and as a secondary Server. The primary Linux-based Server can manage both Linux-based and Windows-based secondary Servers. A primary Windows-based Server can manage a secondary Linux-based Server. The root Administration Server can only act as a primary Server.

You can add an Administration Server as a secondary Administration Server, thus establishing a "primary/secondary" hierarchy.

To add a secondary Administration Server that is available for connection through OSMP Console:

1. Make sure that port 13000 of the future primary Administration Server is available for receipt of connections from secondary Administration Servers.
2. On the future primary Administration Server, click the settings icon ().
3. On the properties page that opens, click the Administration Servers tab.
4. Select the check box next to the name of the administration group to which you want to add the Administration Server.
5. In the menu line, click Connect secondary Administration Server.

   The Add secondary Administration Server wizard starts. Proceed through the wizard by using the Next button.

6. Fill in the following fields:
   • Secondary Administration Server display name

     A name by which the secondary Administration Server will be displayed in the hierarchy. If you want, you can enter the IP address as a name, or you can use a name like, for example, "Secondary Server for group 1".

   • Secondary Administration Server address (optional)

     Specify the IP address or the domain name of the secondary Administration Server.

     This parameter is required if the Connect primary Administration Server to secondary Administration Server in DMZ option is enabled.

   • Administration Server SSL port

     Specify the number of the SSL port on the primary Administration Server. The default port number is 13000.

     For the root Administration Server, this port is 13000 and it cannot be changed.

   • Administration Server API port

     Specify the number of the port on the primary Administration Server for receiving connections over OpenAPI. The default port number is 13299.

   • Connect primary Administration Server to secondary Administration Server in DMZ

     Select this option if the secondary Administration Server is in a demilitarized zone (DMZ).

     If this option is selected, the primary Administration Server initiates connection to the secondary Administration Server. Otherwise, the secondary Administration Server initiates connection to the primary Administration Server.

7. Specify the certificate of the future secondary Server.

   The wizard is complete.

8. Send the certificate file of the future primary Administration Server to the system administrator of the office where the future secondary Administration Server is located. (You can, for example, write the file to an external device, such as a flash drive, or send it by email.)

   The certificate file is located on the future primary Administration Server, at /var/opt/kaspersky/klnagent_srv/1093/cert/.

9. Prompt the system administrator in charge of the future secondary Administration Server to do the following:
   1. Click the settings icon ().
   2. On the properties page that opens, proceed to the Hierarchy of Administration Servers section of the General tab.
   3. Select the This Administration Server is secondary in the hierarchy option.

      The root Administration Server can only act as a primary Server.

   4. In the Primary Administration Server address field, enter the network name of the future primary Administration Server.
   5. Select the previously saved file with the certificate of the future primary Administration Server by clicking Browse.
   6. If necessary, select the Connect primary Administration Server to secondary Administration Server in DMZ check box.
   7. If the connection to the future primary Administration Server is performed through a proxy server, select the Use proxy server option and specify the connection settings.
   8. Click Save.

The "primary/secondary" hierarchy is built. The primary Administration Server starts receiving connection from the secondary Administration Server using port 13000. The tasks and policies from the primary Administration Server are received and applied. The secondary Administration Server is displayed on the primary Administration Server, in the administration group where it was added.

Viewing the list of secondary Administration Servers

To view the list of the secondary (including virtual) Administration Servers:

In the main menu, click the name of the Administration Server, which is next to the settings icon ().

The drop-down list of the secondary (including virtual) Administration Servers is displayed.

You can proceed to any of these Administration Servers by clicking its name.

The administration groups are shown, too, but they are grayed and not available for management in this menu.

If you are connected to your primary Administration Server in OSMP Console, and can not connect to a virtual Administration Server that is managed by a secondary Administration Server, you can use one of the following ways:

• Modify the existing OSMP Console installation to add the secondary Server to the list of trusted Administration Servers. Then you will be able to connect to the virtual Administration Server in OSMP Console.
  1. On the device where OSMP Console is installed, run the OSMP Console installation file corresponding to the Linux distribution installed on your device under an account with administrative privileges.

     The Setup Wizard will start. Proceed through the wizard by using the Next button.

  2. Select the Upgrade option.
  3. On the Modification type step, select the Edit connection settings option.
  4. On the Trusted Administration Servers step, add the required secondary Administration Server.
  5. On the last step, click Modify to apply the new settings.
  6. After the application reconfiguration successfully completes, click the Finish button.
• Use OSMP Console to connect directly to the secondary Administration Server where the virtual Server was created. Then you will be able to switch to the virtual Administration Server in OSMP Console.

Managing virtual Administration Servers

This section describes the following actions to manage virtual Administration Servers:

• Create virtual Administration Servers
• Enable and disable virtual Administration Servers
• Assign an administrator for a virtual Administration Server
• Change the Administration Server for client devices
• Delete virtual Administration Servers

Creating a virtual Administration Server

You can create virtual Administration Servers and add them to administration groups.

To create and add a virtual Administration Server:

1. In the main menu, click the settings icon () next to the name of the required Administration Server.
2. On the page that opens, proceed to the Administration Servers tab.
3. Select the administration group to which you want to add a virtual Administration Server.
   The virtual Administration Server will manage devices from the selected group (including the subgroups).
4. On the menu line, click New virtual Administration Server.
5. On the page that opens, define the properties of the new virtual Administration Server:
   • Name of virtual Administration Server.
   • Administration Server connection address

     You can specify the name or the IP address of your Administration Server.

6. From the list of users, select the virtual Administration Server administrator. If you want, you can edit one of the existing accounts before assigning it the administrator's role, or create a new user account.
7. Click Save.

The new virtual Administration Server is created, added to the administration group and displayed on the Administration Servers tab.

If you are connected to your primary Administration Server in OSMP Console, and can not connect to a virtual Administration Server that is managed by a secondary Administration Server, you can use one of the following ways:

• Modify the existing OSMP Console installation to add the secondary Server to the list of trusted Administration Servers. Then you will be able to connect to the virtual Administration Server in OSMP Console.
  1. On the device where OSMP Console is installed, run the OSMP Console installation file corresponding to the Linux distribution installed on your device under an account with administrative privileges.

     The Setup Wizard will start. Proceed through the wizard by using the Next button.

  2. Select the Upgrade option.
  3. On the Modification type step, select the Edit connection settings option.
  4. On the Trusted Administration Servers step, add the required secondary Administration Server.
  5. On the last step, click Modify to apply the new settings.
  6. After the application reconfiguration successfully completes, click the Finish button.
• Use OSMP Console to connect directly to the secondary Administration Server where the virtual Server was created. Then you will be able to switch to the virtual Administration Server in OSMP Console.

Enabling and disabling a virtual Administration Server

When you create a new virtual Administration Server, it is enabled by default. You can disable or enable it again at any time. Disabling or enabling a virtual Administration Server is equal to switching off or on a physical Administration Server.

To enable or disable a virtual Administration Server:

1. In the main menu, click the settings icon () next to the name of the required Administration Server.
2. On the page that opens, proceed to the Administration Servers tab.
3. Select the virtual Administration Server that you want to enable or disable.
4. On the menu line, click the Enable / disable virtual Administration Server button.

The virtual Administration Server state is changed to enabled or disabled, depending on its previous state. The updated state is displayed next to the Administration Server name.

Assigning an administrator for a virtual Administration Server

When you use virtual Administration Servers in your organization, you might want to assign a dedicated administrator for each virtual Administration Server. For example, this might be useful when you create virtual Administration Servers to manage separate offices or departments of your organization, or if you are an MSP provider and you manage your tenants through virtual Administration Servers.

When you create a virtual Administration Server, it inherits the user list and all of the user rights of the primary Administration Server. If a user has access rights to the primary Server, this user has access rights to the virtual Server as well. After creation, you configure the access rights to the Servers independently. If you want to assign an administrator for a virtual Administration Server only, make sure that the administrator does not have access rights on the primary Administration Server.

You assign an administrator for a virtual Administration Server by granting the administrator access rights to the virtual Administration Server. You can grant the required access rights in one of the following ways:

• Configure access rights for the administrator manually
• Assign one or more user roles for the administrator

To sign in to OSMP Console, an administrator of a virtual Administration Server specifies the virtual Administration Server name, user name, and password. OSMP Console authenticates the administrator and opens the virtual Administration Server to which the administrator has access rights. The administrator cannot switch between Administration Servers.

Prerequisites

Before you start, ensure that the following conditions are met:

• The virtual Administration Server is created.
• On the primary Administration Server, you have created an account for the administrator that you want to assign for the virtual Administration Server.
• You have the Modify object ACLs right in the General features → User permissions functional area.

Configuring access rights manually

To assign an administrator for a virtual Administration Server:

1. In the main menu, switch to the required virtual Administration Server:
   1. Click the chevron icon () to the right of the current Administration Server name.
   2. Select the required Administration Server.
2. In the main menu, click the settings icon () next to the name of the Administration Server.

   The Administration Server properties window opens.

3. On the Access rights tab, click the Add button.

   A unified list of users of the primary Administration Server and the current virtual Administration Server opens.

4. From the list of users, select the account of the administrator that you want to assign for the virtual Administration Server, and then click the OK button.

   The application adds the selected user to the user list on the Access rights tab.

5. Select the check box next to the added account, and then click the Access rights button.
6. Configure the rights that the administrator will have on the virtual Administration Server.

   For successful authentication, at minimum, the administrator must have the following rights:

   • Read right in the General features → Basic functionality functional area
   • Read right in the General features → Virtual Administration Servers functional area

The application saves the modified user rights to the administrator account.

Configuring access rights by assigning user roles

Alternatively, you can grant the access rights to a virtual Administration Server administrator through user roles. For example, this might be useful if you want to assign several administrators on the same virtual Administration Server. If this is the case, you can assign the administrators' accounts the same one or more user roles instead of configuring the same user rights for several administrators.

To assign an administrator for a virtual Administration Server by assigning user roles:

1. On the primary Administration Server, create a new user role, and then specify all of the required access rights that an administrator must have on the virtual Administration Server. You can create several roles, for example, if you want to separate access to different functional areas.
2. In the main menu, switch to the required virtual Administration Server:
   1. Click the chevron icon () to the right of the current Administration Server name.
   2. Select the required Administration Server.
3. Assign the new role or several roles to the administrator account.

The application assigns the roles to the administrator account.

Configuring access rights at the object level

In addition to assigning access rights at the functional area level, you can configure access to specific objects on the virtual Administration Server, for example, to a specific administration group or a task. To do this, switch to the virtual Administration Server, and then configure the access rights in the object's properties.

Changing the Administration Server for client devices

Expand all | Collapse all

You can change the Administration Server that manages client devices to a different Server using the Change Administration Server task. After the task completion, the selected client devices will be put under the management of the Administration Server that you specify.

To change the Administration Server that manages client devices to a different Server:

1. In the main menu, go to Assets (Devices) → Tasks.
2. Click Add.

   The New task wizard starts. Proceed through the wizard by using the Next button.

3. For the Open Single Management Platform application, select the Change Administration Server task type.
4. Specify the name for the task that you are creating.

   A task name cannot be more than 100 characters long and cannot include any special characters ("*<>?\:|).

5. Select devices to which the task will be assigned.
6. Select the Administration Server that you want to use to manage the selected devices.
7. Specify the account settings:
   • Default account

     The task will be run under the same account as the application that performs this task.

     By default, this option is selected.

   • Specify account

     Fill in the Account and Password fields to specify the details of an account under which the task is run. The account must have sufficient rights for this task.

   • Account

     Account under which the task is run.

   • Password

     Password of the account under which the task will be run.

8. If on the Finish task creation page you enable the Open task details when creation is complete option, you can modify the default task settings. If you do not enable this option, the task is created with the default settings. You can modify the default settings later, at any time.
9. Click the Finish button.

   The task is created and displayed in the list of tasks.

10. Click the name of the created task to open the task properties window.
11. In the task properties window, specify the general task settings according to your needs.
12. Click the Save button.

    The task is created and configured.

13. Run the created task.

After the task is complete, the client devices for which it was created are put under the management of the Administration Server specified in the task settings.

Deleting a virtual Administration Server

When you delete a virtual Administration Server, all of the objects created on the Administration Server, including policies and tasks, will be deleted as well. The managed devices from the administration groups that were managed by the virtual Administration Server will be removed from the administration groups. To return the devices under management of Kaspersky Next XDR Expert, run the network polling, and then move the found devices from the Unassigned devices group to the administration groups.

To delete a virtual Administration Server:

1. In the main menu, click the settings icon () next to the name of the Administration Server.
2. On the page that opens, proceed to the Administration Servers tab.
3. Select the virtual Administration Server that you want to delete.
4. On the menu line, click the Delete button.

The virtual Administration Server is deleted.

Configuring Administration Server connection events logging

The history of connections and attempts to connect to the Administration Server during its operation can be saved to a log file. The information in the file allows you to track not only connections inside your network infrastructure, but unauthorized attempts to access the server as well.

To log events of connection to the Administration Server:

1. In the main menu, click the settings icon () next to the name of the required Administration Server.

   The Administration Server properties window opens.

2. On the General tab, select the Connection ports section.
3. Enable the Log Administration Server connection events option.

All further events of inbound connections to the Administration Server, authentication results, and SSL errors will be saved to the file /var/opt/kaspersky/klnagent_srv/logs/sc.syslog.

Setting the maximum number of events in the event repository

In the Events repository section of the Administration Server properties window, you can edit the settings of events storage in the Administration Server database by limiting the number of event records and record storage term. When you specify the maximum number of events, the application calculates an approximate amount of storage space required for the specified number. You can use this approximate calculation to evaluate whether you have enough free space on the disk to avoid database overflow. The default capacity of the Administration Server database is 400,000 events. The maximum recommended capacity of the database is 45 million events.

The application checks the database every 10 minutes. If the number of events reaches the specified maximum value plus 10,000, the application deletes the oldest events so that only the specified maximum number of events remains.

When the Administration Server deletes old events, it cannot save new events to the database. During this period, information about events that were rejected is written to the operating system log. The new events are queued and then saved to the database after the deletion operation is complete. By default, the event queue is limited to 20,000 events. You can customize the queue limit by editing the KLEVP_MAX_POSTPONED_CNT flag value.

To limit the number of events that can be stored in the events repository on the Administration Server:

1. In the main menu, click the settings icon () next to the name of the required Administration Server.

   The Administration Server properties window opens.

2. On the General tab, select the Events repository section. Specify the maximum number of events stored in the database.
3. Click the Save button.

Changing DBMS credentials

Sometimes, you may need to change DBMS credentials, for example, in order to perform a credential rotation for security purposes.

To change DBMS credentials in a Linux environment by using the klsrvconfig utility:

1. Launch a Linux command line.
2. Specify the klsrvconfig utility in the opened command line window:

   sudo /opt/kaspersky/ksc64/sbin/klsrvconfig -set_dbms_cred

3. Specify a new account name. You should specify credentials of an account that exists in the DBMS.

4. Enter a new password.
5. Specify the new password for confirmation.

The DBMS credentials are changed.

Backup copying and restoration of the Administration Server data

Data backup allows you to save the Administration Server data in a certain state, and restore the data if needed, for example, if the Administration Server data is corrupted.

Before you back up the Administration Server data, check whether a virtual Administration Server is added to the administration group. If a virtual Administration Server is added, make sure that an administrator is assigned to this virtual Administration Server before the backup. You cannot grant the administrator access rights to the virtual Administration Server after the backup. Note that if the administrator account credentials are lost, you will not be able to assign a new administrator to the virtual Administrator Server.

You can create a backup copy of the Administration Server data only by running the Backup of Administration Server data task. This task is automatically created when you deploy Kaspersky Next XDR Expert.

On the primary Administration Server, creating and removing the Backup of Administration Server data task is not available.

The backup copy is saved in the /var/spool/ksc/backup directory. The backup directory is automatically created on the worker node on which Administration Server is installed when you deploy Kaspersky Next XDR Expert. On the primary Administration Server, you cannot change the backup directory path.

The following data is saved in the backup copy of Administration Server:

• Database of Administration Server (policies, tasks, application settings, events saved on the Administration Server)
• Configuration details of the structure of administration groups and client devices
• Repository of distribution packages of applications for remote installation
• Administration Server certificate

Recovery of the Administration Server data is only possible by using the KDT utility.

You can create a backup copy of the KUMA Core and restore it from the backup if needed. You can also back up other Kaspersky Next XDR Expert components by using third-party tools only if you use the DBMS installed on a separate server outside the Kubernetes cluster. You must not create the Administration Server database backup by using third-party tools.

Configuring the Administration Server Backup task

The Administration Server Backup task automatically is created when you deploy Kaspersky Next XDR Expert and cannot be deleted. You can create a backup copy of Administration Server data only by running the Administration Server Backup task.

To configure the Backup of Administration Server data task:

1. In the main menu, go to Assets (Devices) → Tasks, and then select the Administration Server Backup task.
2. Click the Administration Server Backup task.

   The task properties window opens.

3. If necessary, specify the general task settings according to your needs.
4. In the Application settings section, set the backup protection password and number of backup copies if needed.

   We recommend limiting the number of Administration Server data backups, to avoid overflow in the disk space allocated to store backups.

5. Click Save to apply changes.

The Backup of Administration Server data task is configured.

Using the KDT utility to recover Administration Server data

The Backup of Administration Server data task allows you to copy Administration Server data for backup. To recover Administration Server data, you must use the KDT utility.

To recover Administration Server data:

1. On the administrator host where the KDT utility is located, run the following command:

   ./kdt invoke ksc --action listBackup

   The list of backups located in the /var/spool/ksc/backup directory is displayed.

2. Run the following command:

   ./kdt invoke ksc --action restoreBackup --param ksc_file_backup='<file name>' --param ksc_backup_password="<password>"

   where:

   • ksc_file_backup is the path to the required backup archive and the archive name.
   • ksc_backup_password is the archive password if the backup was saved with a password. If no password was used set the ksc_backup_password variable to "".

The Administration Server data is recovered from the selected backup archive.

Deleting a hierarchy of Administration Servers

If you no longer want to have a hierarchy of Administration Servers, you can disconnect them from this hierarchy.

To delete a hierarchy of Administration Servers:

1. In the main menu, click the settings icon () next to the name of the primary Administration Server.
2. On the page that opens, proceed to the Administration Servers tab.
3. In the administration group from which you want to delete the secondary Administration Server, select the secondary Administration Server.
4. On the menu line, click Delete.
5. In the window that opens, click OK to confirm that you want to delete the secondary Administration Server.

The former primary Administration Server and the former secondary Administration Server are now independent of each other. The hierarchy no longer exists.

Access to public DNS servers

If access to Kaspersky servers by using the system DNS is not possible, Open Single Management Platform can use the following public DNS servers, in the following order:

1. Google Public DNS (8.8.8.8)
2. Cloudflare DNS (1.1.1.1)
3. Alibaba Cloud DNS (223.6.6.6)
4. Quad9 DNS (9.9.9.9)
5. CleanBrowsing (185.228.168.168)

Requests to these DNS servers may contain domain addresses and the public IP address of the Administration Server, because the application establishes a TCP/UDP connection to the DNS server. If Open Single Management Platform is using a public DNS server, data processing is governed by the privacy policy of the relevant service.

To configure the use of public DNS by using the klscflag utility:

1. On the administrator host where the KDT utility is located, run the following command to disable the use of public DNS:

   ./kdt invoke ksc --action klscflag --param klscflag_param=" -fset -pv ".core/.independent" -s Transport -n ForceUseSystemDNS -t d -v 1"

2. To enable the use of public DNS, run the following command:

   ./kdt invoke ksc --action klscflag --param klscflag_param=" -fset -pv ".core/.independent" -s Transport -n ForceUseSystemDNS -t d -v 0"

Configuring the interface

You can configure the OSMP Console interface to display and hide sections and interface elements, depending on the features being used.

To configure the OSMP Console interface in accordance with the currently used set of features:

1. In the main menu, go to your account settings, and then select Interface options.
2. In the Interface options window that opens, enable or disable the Show data encryption and protection option.
3. Click Save.

After that, the Operations → Data encryption and protection section appears in the main menu.

Encrypt communication with TLS

To fix vulnerabilities on your organization's corporate network, you can enable traffic encryption by using the TLS protocol. You can enable TLS encryption protocols and supported cipher suites on Administration Server. Open Single Management Platform supports the TLS protocol versions 1.0, 1.1, 1.2, and 1.3. You can select the required encryption protocol and cipher suites.

Open Single Management Platform uses self-signed certificates. You can also use your own certificates. We recommend using certificates issued by trusted certificate authorities.

To configure allowed encryption protocols and cipher suites on Administration Server:

1. On the administrator host where the KDT utility is located, run the following command:

   ./kdt invoke ksc --action klscflag --param klscflag_param=" -fset -pv ".core/.independent" -s Transport -n SrvUseStrictSslSettings -v <value> -t d"

   Use the SrvUseStrictSslSettings flag to configure allowed encryption protocols and cipher suites on Administration Server.

   Specify the <value> parameter of the SrvUseStrictSslSettings flag:

   • 4—Only the TLS 1.2 and TLS 1.3 protocols are enabled. Also, cipher suites with TLS_RSA_WITH_AES_256_GCM_SHA384 are enabled (these cipher suites are needed for backward compatibility with Kaspersky Security Center 11). This is the default value.

     Cipher suites supported for the TLS 1.2 protocol:

     • ECDHE-RSA-AES256-GCM-SHA384
     • ECDHE-RSA-AES256-SHA384
     • ECDHE-RSA-CHACHA20-POLY1305
     • AES256-GCM-SHA384 (cipher suite with TLS_RSA_WITH_AES_256_GCM_SHA384)
     • ECDHE-RSA-AES128-GCM-SHA256
     • ECDHE-RSA-AES128-SHA256

     Cipher suites supported for the TLS 1.3 protocol:

     • TLS_AES_256_GCM_SHA384
     • TLS_CHACHA20_POLY1305_SHA256
     • TLS_AES_128_GCM_SHA256
     • TLS_AES_128_CCM_SHA256
   • 5—Only the TLS 1.2 and TLS 1.3 protocols are enabled. For the TLS 1.2 and TLS 1.3 protocols, the specific cipher suites listed below are supported.

     Cipher suites supported for the TLS 1.2 protocol:

     • ECDHE-RSA-AES256-GCM-SHA384
     • ECDHE-RSA-AES256-SHA384
     • ECDHE-RSA-CHACHA20-POLY1305
     • ECDHE-RSA-AES128-GCM-SHA256
     • ECDHE-RSA-AES128-SHA256

     Cipher suites supported for the TLS 1.3 protocol:

     • TLS_AES_256_GCM_SHA384
     • TLS_CHACHA20_POLY1305_SHA256
     • TLS_AES_128_GCM_SHA256
     • TLS_AES_128_CCM_SHA256

   We do not recommend using 0, 1, 2, or 3 as the parameter value of the SrvUseStrictSslSettings flag. These parameter values correspond to insecure TLS protocol versions (the TLS 1.0 and TLS 1.1 protocols) and insecure cipher suites, and are used only for backward compatibility with earlier Kaspersky Security Center versions.

2. Restart the following Open Single Management Platform services:
   • Administration Server
   • Web Server
   • Activation Proxy

Traffic encryption by using the TLS protocol is enabled.

You can use the KLTR_TLS12_ENABLED and KLTR_TLS13_ENABLED flags to enable the support of the TLS 1.2 and TLS 1.3 protocols, respectively. These flags are enabled by default.

To enable or disable the support of the TLS 1.2 and TLS 1.3 protocols,

On the administrator host where the KDT utility is located, run one of the following commands:

• To enable or disable the support of the TLS 1.2 protocol:

  ./kdt invoke --action klscflag --param klscflag_param=" -fset -pv ".core/.independent" -s Transport -n KLTR_TLS12_ENABLED -v <value> -t d"

• To enable or disable the support of the TLS 1.3 protocol:

  ./kdt invoke --action klscflag --param klscflag_param=" -fset -pv ".core/.independent" -s Transport -n KLTR_TLS13_ENABLED -v <value> -t d"

Specify the <value> parameter of the flag:

• 1—To enable the support of the TLS protocol.
• 0—To disable the support of the TLS protocol.