A traffic monitoring solution (man-in-the-middle) which tries to decrypt the connection to KSC initiated by mmc console over the TCP port 13291. To do this, it replaces the certificate by it's own, self signed in most cases.
KSC Administrator might be unaware of this fact.
They try to connect to KSC Server remotely but receive Invalid certificate error.

Troubleshooting steps

1. Make sure the problem is not reproduced when connecting to KSC Server locally by using the localhost address – it is unlikely that traffic inspection monitors local traffic: 
   
2. Run the following commands on the host where the problem is observed and on the host where the connection is successful via https://sourceforge.net/projects/openssl-for-windows/
   command to run
   

   echo Q | openssl s_client -connect KSCipaddress:13291 -showcerts >certinfo.txt 2>&1
3. Info about certificate will be saved to certinfo.txt, compare them to find differences.
4. Collect MMC Console and $klserver* trace logs when the problem is reproduced and when it is not. Network traffic dump collected on both computers is nice to have but not obligatory.
5. Create a support ticket with collected information.

The KSC Web Console is used to export a list of devices, but it is unable to export the column for the operating system.

1. Log in to the KSC Web Console.
2. Go to Assets (Devices) → Managed devices, and check the Operating System column.
3. Export the list to CSV or TXT
4. Operating System column cannot be displayed.

Reason and solution

This issue is fixed in KSC Linux 15.3.

Follow the steps to fix the issue in KSC for Windows:

1. Install Python 3.12: https://www.python.org/
2. Install urllib3 and KlAkOAPI libraries: https://support.kaspersky.com/ksc/15.1/211453?version=latest
3. Download the script custom_script_operating_system_details.zip
4. Extract cmd and py files to Python installation folder.
5. Run the script by running the cmd file.

When deploying Auto patches from KSC, installing Network Agent or Kaspersky Endpoint Security, installation fails with bad junction errors.

Diagnostics

• While Auto patch deployments over KSC will directly generate an event in Events section of KSC, manual Network Agent or KES installations will end with Fatal Error message and installation logs will contain information such as below:
  • Application: Kaspersky Security Center Network Agent – Error 25002. Error while installing: Error 1205/0x0 (‘The system cannot find the path specified.’) accessing filesystem object ‘C:\ProgramData\Application Data\KasperskyLab\adminkit\data\.bases’.
  • Error 25002. Error while installing: Error 1205/0x0 (‘The system cannot find the path specified.’) accessing filesystem object ‘C:\ProgramData\Application Data\KasperskyLab\adminkit\data\.bases’.
     
• A GSI collected from the device will also contain a txt file named Junction_ProgramData_PCNAME.txt which will show faulty junction points that prevent installation.

GSI log:

Junction Point Log with Junction:

• To find bad junction points manually, you check use the command below in CMD:

  dir /AL C:\ProgramData 

   

Workaround & Solution

To remove the faulty link, you must follow the steps below:

• Open a CMD Prompt with elevated account 
• Run the commands below (According to our example above, the fault junction point shows Z:\ drive)

rem In order to delete the link, you must first access the directory.
cd C:\Programdata
rem Removing the link
rd "Application Data"
rem Recreating the link is not mandatory as the installation itself will create the link if not found
mklink /J "C:\ProgramData\Application Data" C:\ProgramData  

These 3 commands can be used to create a batch file to be sent to multiple devices that are having the issue.

1. First of all view list of updates aimed at installation on client. For this purpose in network agent trace file search for ‘Update to install:’ without quotes. You will get results similar to:

   Quote

   02.12.2024 11:39:59.052 00003254.00004E10 L4  KLNAG: Update to install: b4205e28-dcd2-406f-bcf6-efc5a342c8cb # 200 {2024-11 .NET 6.0.36 Update for x64 Client (KB5047486)}, type = 1

    02.12.2024 11:39:59.049 00003254.00004E10 L4  KLNAG: Update to install: 79ae03df-d6eb-4de2-b59f-37e963d7a69e # 101 {Обновление пакета Office 2003 (KB907417)}, type = 1

   02.12.2024 11:39:59.053 00003254.00004E10 L4  KLNAG: Update to install: 3fefb63f-4dfc-49c4-85db-d40dd6ea3f22 # 102 {Обновление фильтра нежелательной почты для Outlook 2003 (KB2598343)}, type = 1

   etc.
   Some of found updates are skipped by filters so pay attention to skipped updates and to overall number of updates that should be installed.
   

2. Some updates might already be downloaded to the target system so at the second step identify which update files are already downloaded and which should be downloaded. In network agent trace file search for ‘is already downloaded’ and ‘needs to be downloaded’ without quotes. In our sample traces results are:

   Quote

   02.12.2024 11:39:59.066 00003254.00004E10 L4  KLNAG: Update 79ae03df-d6eb-4de2-b59f-37e963d7a69e#101 needs to be downloaded.

   02.12.2024 11:39:59.069 00003254.00004E10 L4  KLNAG: Update e2bd7f45-47f9-402f-8fda-14f78030fe70#111 is already downloaded.

   02.12.2024 11:39:59.071 00003254.00004E10 L4  KLNAG: Update 1e2a55d2-be5f-42da-86a4-8a4135816201#101 is already downloaded.

   02.12.2024 11:39:59.074 00003254.00004E10 L4  KLNAG: Update c9951ae6-3676-4751-b4ce-b94a5df7e010#200 is already downloaded.

   02.12.2024 11:39:59.076 00003254.00004E10 L4  KLNAG: Update d1f7bb56-bd76-4a9f-b8bd-8a5d60807ee9#200 is already downloaded.

   02.12.2024 11:39:59.078 00003254.00004E10 L4  KLNAG: Update f4588607-516b-44af-8ec8-62b7c089c5c7#200 is already downloaded.

   02.12.2024 11:39:59.080 00003254.00004E10 L4  KLNAG: Update 4e3f49d6-694a-4e71-a160-abbdb739fe4b#201 is already downloaded.

   02.12.2024 11:39:59.082 00003254.00004E10 L4  KLNAG: Update 9e4c727d-dec7-406e-98e0-1a7d44590f52#200 is already downloaded.

   02.12.2024 11:39:59.084 00003254.00004E10 L4  KLNAG: Update b4205e28-dcd2-406f-bcf6-efc5a342c8cb#200 is already downloaded.

3. Match code of update which needs to be downloaded (79ae03df-d6eb-4de2-b59f-37e963d7a69e) with results detected at step 1 and you will see that KB907417 needs to be downloaded.

4. Open MS Update catalog and search for KB907417. In search results click ‘Download’ button and observe window with results:
   
   Name of archive containing required update KB907417 is: otkloadr_c87e2fe94dd873224afa65e2af2473ca3e307a37.cab

5. Search for c87e2fe94dd873224afa65e2af2473ca3e307a37.cab in WindowsUpdate.log from client machine. Pay attention to the found lines:
    

   Quote

   2024.11.22 13:35:59.8856907 18332 18860 DownloadManager Downloading from http://localhost:11696/C87E2FE94DD873224AFA65E2AF2473CA3E307A37.cab to C:\WINDOWS\SoftwareDistribution\Download\48ec39650764ea7a46ebe67ecf3b6f47\OTKLOADR.CAB (full file).

   2024.11.22 13:36:00.4933414 18332 15660 Misc            Validating signature for C:\WINDOWS\SoftwareDistribution\Download\48ec39650764ea7a46ebe67ecf3b6f47\OTKLOADR.CAB with dwProvFlags 0x00000080:

   2024.11.22 13:36:00.5430357 18332 15660 Misc            *FAILED* [80096002] Error: verifying trust for C:\WINDOWS\SoftwareDistribution\Download\48ec39650764ea7a46ebe67ecf3b6f47\OTKLOADR.CAB

   2024.11.22 13:36:01.2455912 18332 15660 DownloadManager *FAILED* [80096004] Failed to postprocess the file: URL = 'http://localhost:11696/C87E2FE94DD873224AFA65E2AF2473CA3E307A37.cab', Local path = 'C:\WINDOWS\SoftwareDistribution\Download\48ec39650764ea7a46ebe67ecf3b6f47\OTKLOADR.CAB'

6. Search for otkloadr_c87e2fe94dd873224afa65e2af2473ca3e307a37.cab in administration server trace file to find URL used by administration server to download required update from MS servers:

   Quote

   02.12.2024 11:41:34.929 0000A528.00009DD0 L4  KLSRV: KLSRV::SrvTskSysPatch::DoTask: wstrMUUrl='http://www.download.windowsupdate.com/msdownload/update/software/crup/2008/02/otkloadr_c87e2fe94dd873224afa65e2af2473ca3e307a37.cab',

7.  Now once we know the name of problem update you may offer the customer to temporarily exclude KB907417 from update installation task to let other updates to be installed. Then proceed with investigation.

8. On Administration server use web browser to download problem update from the link identified at step 6 and make sure that its signature is valid. It should look like on below screenshots
   
   In case if Digital Signatures tab is not present in properties of this file or signature is invalid then try to re-download with disabled AV solution. If this does not help then make sure that no proxy/firewall affect this issue. Verify that MS certificates are up to date on KSC server. In MMC console / Software updates node right click on KB907417 and ‘Delete update files’. Try to launch updates installation task again.

9. On client machine use web browser to download problem update using link identified at step 5. Verify its signature and proceed same way as in step 8. Additionally compare downloaded file with C:\WINDOWS\SoftwareDistribution\Download\48ec39650764ea7a46ebe67ecf3b6f47\OTKLOADR.CAB. Verify diginal signature of OTKLOADR.CAB

10. You may use signtool.exe to verify signature of .cab files on server and client:

    signtool.exe verify /pa otkloadr_c87e2fe94dd873224afa65e2af2473ca3e307a37.cab

    
    The utility signtool.exe goes as part of Windows SDK. It is available at C:\<Path to Windows SDK>\<version>\bin\<build number>\x64\signtool.exe

11. In case if digital signature appears to be correct then use standard recommendations for resetting WUA:

    net stop wuauserv
    net stop cryptSvc
    net stop bits
    net stop msiserver
    

    Rename folders

    Quote

    C:\Windows\SoftwareDistribution -> C:\Windows\SoftwareDistribution.old

    C:\Windows\System32\catroot2 -> C:\Windows\System32\catroot2.old

    Del "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\qmgr*.dat"
    net start wuauserv
    net start cryptSvc
    net start bits
    net start msiserver

12.  After resetting WUA launch ‘Find updates and critical vulnerabilities’ task. It might fail several times because WUA cache was cleared. So after getting error just re-launch task again. Once 'find updates' task completes successfully launch task to install updates and fix vulnerabilities (problem update should be included in task scope this time). Observe the results.

You may want to allow certain users to do everything, but without giving them access to modify policies, manage users, or assign roles. However, when using default roles provided by KSC, some permissions are either too broad or unchangeable.

Steps to Create the Custom Role:

1. Open Kaspersky Security Center.
2. Go to Administration Server Properties → Users Roles.

1. Click “Add” to create a new role.
2. Enter a role name (e.g., Rule for Hospitals).
3. In the Rights tab:
   • Allow the necessary permissions such as:
     • View reports
     • Run tasks
     • Monitor devices
   • Do not grant permissions related to:
     • Policy creation
     • Policy editing
     • Policy assignment

1. Click OK to save the role.

Assign the Role:

1. Go to Security → Users.
2. Select the user or group who needs restricted access.
3. Assign the newly created role (Rule for Hospitals) to them.

Result:

• The user can perform routine operations like monitoring, Running tasks and Reporting.
• The user cannot:
  • Modify policies

• • Manage or assign users and roles

• Ensures security, compliance, and accountability across the KSC environment.

Step-by-step guide

To export task execution history, follow these steps:

1. Open task results window.

   
     
2. In the upper part of the task results window, select problem computer.
    
3. Right-click some event in the lower part of the task results window, where task execution history for selected host displayed.  
4. In context menu, choose Export… option. Events export Wizard will start.
    
    
5. Click "Browse" button, select file destination and file name. Save events to .txt file. Make sure option Export selected events only NOT enabled.
    
    
6. Click “Next” button.
7. Select option “Export as tab-delimited Unicode text”. Click “Next” button and complete the wizard.
    
    

Step-by-step guide

Make sure that System Management license is installed, otherwise KSC events won't be exported to SIEM. For more information please refer to SIEM integration: the most frequent error.
 

1. Specify Splunk Server address and port;
   
   
   
    
2. Login into Splunk Management console;
   
   
   
    
3. Press Settings → Configure data inputs;
   
   
   
    
4. In the opened Add Data window 
   - select TCP;
   - Specify Port you are planning to use. And a Source (KSC server address or DNS-name).
   
   
   
    
5. Configure Source type: choose Select and pick syslog from drop down menu. Configure Host: set IP for Method 
   
   
   
    
6. Check the settings on a result screen;
   
   
   
    
7. Open Splunk home page and press Search & Reporting;
   
   
   
    
8. Make sure that KSC event were indexed by Splunk correctly as expected;
   
   
   
    
9. Right now you are able to see raw KSC events.
   
   

Problem

You set up integration with SIEM but no events come up on SIEM side. In some cases there is no incoming traffic to SIEM from KSC server.

Solution

In vast majority of cases the root cause can be located in KSC server trace

Starting from KSC 11 you can export events to SIEM via Syslog without a Vulnerability and Patch Management (Systems Management) license.

For KSC 15.1 and later, a commercial license is not checked anymore when you export events to a SIEM system in the CEF or LEEF formats: https://support.kaspersky.com/KSC/15.1/en-US/12521.htm

If you can find such a line, make sure that Systems management license is installed on KSC. If the issue reproduces with SM license installed do the following:

1. Enable admin server tracing
2. Click 'Export archive' button
3. Wait 15 minutes
4. Provide Customer Support (https://companyaccount.kaspersky.com/) with the traces, GSI file (https://support.kaspersky.com/common/diagnostics/3632 - do not forget to switch on the event logs collection), and the detailed problem description.

Those passwords have 16 characters length, characters are taken randomly so that the password contain 3 out of 4 of the following groups of characters:

• Lowercase characters (a – z)
• Uppercase characters (A – Z)
• Numbers (0-9)
• Symbols (~ ! @ # $ % ^ & * - _ + = [ ] { } | \ : ' , . ? / ` ~ " < > ( )
• Also the password cannot contain a dot character '.' immediately preceding the '@' symbol.

Step-by-step guide

To do so:

1. Import klakaut-on_x*.reg file.

2. Restart klakaut service.

   net stop klakaut net start klakaut

3. Enable another trace if required.
4. Reproduce the issue.
5. Import klakaut-off_x*.reg file.
6. Trace file $klakaut-klakaut.log will be placed in C:\Windows\Temp.

Step-by-step guide

To collect traces:

1. Download archive
2. Use trace-5-snmpagt.reg to start trace
3. Reproduce the issue
4. Use trace-off-snmpagt.reg to stop trace
5. Archive files and send to Kaspersky Support.

The article is giving some use cases examples of KSC API calls to ease one's start using the API. In that KB we are looking at host isolation with KES/KEA scenario.

Details

Prerequisites

• internal user: api-user

Example

• KSC address - 127.0.0.1 (the address can also be external)
• API Port - 13299 (default)
• User: api-user (intrental KSC user), base64: YXBpLXVzZXI=
• Password: password, base64: cGFzc3dvcmQ=

• Credentials:

  	User	Password
  	api-user	password
  Base64:	YXBpLXVzZXI=	cGFzc3dvcmQ=

• Authentication, type: Authenticated session, other types: KSC Open API description
• Requests are in cUrl and http formats, as an alternative it is also possible to use Python library (KlAkOAPI Python package)

Login

Start connection to KSC (Session::StartSession)

Username and password should be encoded to base64 format as part of a secure HTTPS session. For example, https://www.base64encode.org/ can be used for encoding.

Use this token in request header

Find Host

Find host by filter string (HostGroup::FindHosts)

Filter string, contains a condition over host attributes, see also Search filter syntax.

We use "KLHST_WKS_DN" - Host display name

Response ID

Copy Accessor for next request (ChunkAccessor::GetItemsChunk)

Response info about host:

Copy value "KLHST_WKS_HOSTNAME" for next request

KEA Isolation

HostGroup.GetHostInfo

Acquire specified host attributes. (HostGroup::GetHostInfo)

HostGroup.SS_GetNames

Get section names from host settings storage. (HostGroup::SS_GetNames)

Parameters values should be taken from the previous response.

Response:

With NWC web console KSC create local network exteption for VPN:

1) Open host properties → Applications → KEA

2) Open tab APP Settings → Network Isolation → Isolation on detection

3) Add rule for RDP → click "OK" → click "Save"

HostGroup.SS_Read

Read data from host settings storage. (HostGroup::SS_Read)

Parameters values should be taken from two previous responses

Response info about Network Isolation with RDP rule exception:

Copy all response for next request.

HostGroup.SS_Write

Write data to host settings storage for isolation workstation with RDP rule. (HostGroup::SS_Write)

1) Use previous value parameters

2) for nOption use 7

• 7 - "Clear", replaces existing section contents with pData, i.e. existing section contents will deleted and variables from pData will be written to the section. 

3) for pSettings past previous response and change 

"Enable": true

Response

Host isolated successfully.

For off isolation you must change for pSettings past previous response and change 

"Enable": false

Problem:

KSC certificate renewal or replacement is made incorrectly because the option to instantly replace the server certificate is used.

Cause:

After the certificate is renewed with "-t C" option, network agents do not receive a new certificate and have no connection to the server.

Solution:

In order to avoid such issues, run the certificate renewal script using the "-t CR" option (CR — Replace the common reserve certificate for ports 13000 and 13291) and the "-f" option in the <dd.mm.yyyy> format where we indicate the date 3–4 weeks ahead the current one.

The time we set aside for changing the certificate to a backup one will allow a new certificate to be distributed to all Kaspersky Network Agents (Nagent):

For example, consider the command "klsetsrvcert.exe -f "DD-MM-YYYY hh:mm" -t CR -g nb.loc". Since this command was used in October, a backup certificate would be created and distributed to all nagents within a month. Thus, the certificate should have been applied on November 1, 2022. 

Checking the reserve certificate date

1. Run the Windows command prompt by using administrator rights, and then change your current directory to the directory with the klsrvcert utility. The utility is located in the folder where Administration Server or Kaspersky Network agent is installed. The default installation path is <Disk>:\Program Files (x86)\Kaspersky Lab\Kaspersky Security Center\ or <Disk>:\Program Files (x86)\Kaspersky Lab\NetworkAgent\.
2. Run

   klscflag.exe -ssvget -pv 1103/1.0.0.0 -s KLNAG_SECTION_CERTDATA -n KLNAG_SSL_SERVER_CERT_RESERVE -ss '|ss_type =    \"SS_LOCAL_MACHINE\";'

    

3. Enter the resulting number in a converter to see the human-readable date: https://www.epochconverter.com/ 
   

Verification of reserve certificate on managed hosts

Let's check if the backup certificate has applied to the host. To do this, using the klscflag utility, enter the command: klscflag.exe -ssvget -pv 1103/1.0.0.0 -s KLNAG_SECTION_CERTDATA -n KLNAG_SSL_SERVER_CERT_RESERVE -ss '|ss_type = \"SS_LOCAL_MACHINE\";'

The certificate has been delivered.
If the backup certificate is not yet delivered to the destination host, we will see the following result of this command:

Verification of reserve certificate on secondary administration servers
When the command to renew the certificate on primary server is issued, the activity is logged to C:\ProgramData\KasperskyLab\adminkit\logs\CertRenewSysLogName.syslog.

Open it on primary server and check the recent entry containing "Server reserve certificate", for example:

Цитата

<142>1 2025-06-16T15:01:46.488Z ksc.ksctest.local CertRenewSysLogName 3228 - - Server reserve certificate is stored in global storage (certificate '2D2D2D2D2D424547494E2043455254494649434154452D2D2D2D2D0A4D494944766A434341716167417749424167495556424D7454645456614133346A5431467675743548365265784A45774451594A4B6F5A496876634E4151454C0A42514177484445614D426747413155454177775261334E6A4C6D747A5933526C633351756247396A595777774868634E4D6A55774E5445334D5455774D5451310A5768634E4D6A59774E6A45344D5455774D545131576A41634D526F7747415944565151444442467263324D7561334E6A6447567A6443357362324E68624443430A415349774451594A4B6F5A496876634E4151454242514144676745504144434341516F4367674542414C7651614E4273303436574D4C65696A42384D7656306F0A56346469776673486B6730303967524D4B75737A724A5130305746746C6B76743577493955414559467456756D30714E68447154354367476B5449716F4B514B0A315470336F52725047486F30534C694A6B6F6441416B346E6374597A634D33736352775533445735776F5946486E62344E7245744B7468433755344F587669620A464A2F766E65734A6E50556D4C4147503239726A5356456F2B6D5934354269666F4E3377654E497830392B6A32647753513176626B4A4C6942566A66777034370A68784D7230523845792F3334706F54505450346E49326E727759444B4547366259486A38746B6F72554A73706145562F496B42566C50664A2B7854566E666B4F0A2F445838567959324B4250534476736B3145384C666E444339534F704948755957614D6E5A644D766153625765396B6E447A785152706E682F737241795263430A4177454141614F42397A43423944416342674E5648524945465441546768467263324D7561334E6A6447567A6443357362324E686244416342674E56485245450A465441546768467263324D7561334E6A6447567A6443357362324E686244414C42674E564851384542414D4341615977485159445652304F42425945464D32750A4B7276667472324D56767147302F6168497270593652434B4D46634741315564497752514D453641464A56614A7352764757796958712F624461376C4D4B2F490A706D487A6F53436B486A41634D526F7747415944565151444442467263324D7561334E6A6447567A6443357362324E6862494955555A356B32544544676A78320A523562343041466A2B787A667770497745675944565230544151482F42416777426745422F7749424144416442674E5648535545466A415542676772426745460A42516344415159494B775...

This certificate should be propagated automatically to all secondary servers within the remaining time, before the common certificate expires.  

In case there is at least one secondary KSC Server connected to the primary KSC, run the following sql query against the database used by each secondary server:

ms sql query to be run on secondary KSC Server

USE KAV;
select imgMasterReservedCert ReserveCertificatefrom from aksrv_server_props;

KAV is the name of database used by a secondary server. 
The script will display the identifier of primary KSC reserve certificate received by the secondary administration server - it should party match the number from syslog displayed above:

Цитата

0x2D2D2D2D2D424547494E2043455254494649434154452D2D2D2D2D0A4D494944766A434341716167417749424167495556424D7454645456614133346A5431467675743548365265784A45774451594A4B6F5A496876634E4151454C0A42514177484445614D426747413155454177775261334E6A4C6D747A5933526C633351756247396A595777774868634E4D6A55774E5445334D5455774D5451310A5768634E4D6A59774E6A45344D5455774D545131576A41634D526F7747415944565151444442467263324D7561334E6A6447567A6443357362324E68624443430A415349774451594A4B6F5A496876634E4151454242514144676745504144434341516F4367674542414C7651614E4273303436574D4C65696A42384D7656306F0A56346469776673486B6730303967524D4B75737A724A5130305746746C6B76743577493955414559467456756D30714E68447154354367476B5449716F4B514B0A315470336F52725047486F30534C694A6B6F6441416B346E6374597A634D33736352775533445735776F5946486E62344E7245744B7468433755344F587669620A464A2F766E65734A6E50556D4C4147503239726A5356456F2B6D5934354269666F4E3377654E497830392B6A32647753513176626B4A4C6942566A66777034370A68784D7230523845792F3334706F54505450346E49326E727759444B4547366259486A38746B6F72554A73706145562F496B42566C50664A2B7854566E666B4F0A2F445838567959324B4250534476736B3145384C666E444339534F704948755957614D6E5A644D766153625765396B6E447A785152706E682F737241795263430A4177454141614F42397A43423944416342674E5648524945465441546768467263324D7561334E6A6447567A6443357362324E686244416342674E56485245450A465441546768467263324D7561334E6A6447567A6443357362324E686244414C42674E564851384542414D4341615977485159445652304F42425945464D32750A4B7276667472324D56767147302F6168497270593652434B4D46634741315564497752514D453641464A56614A7352764757796958712F624461376C4D4B2F490A706D487A6F53436B486A41634D526F7747415944565151444442467263324D7561334E6A6447567A6443357362324E6862494955555A356B32544544676A78320A523562343041466A2B787A667770497745675944565230544151482F42416777426745422F7749424144416442674E5648535545466A415542676772426745460A42516344415159494B775........

In case there are secondary KSC Servers located in DMZ, KSC should be able to connect to them to download the certificate. If no info about secondary server's certificate is stored in the database of primary server, the automatic renewal of secondary server's certificate will not work properly. secondary server will be disconnected when the certificate expires and should be re-connected manually by KSC Administrator. 

In order to avoid such situation, use the following sql query to make sure all certificates of secondary server have been received by primary KSC successfully:

Query to be run on primary KSC:

select Hosts.strDisplayName SecondaryServerName,
cast(cast(child_servers.imgCertificate as varbinary(max)) as varchar(max)) as SecSrvCurrentCert,
cast(cast(child_servers.imgReserveCert as varbinary(max)) as varchar(max)) as SecSrvReserveCert
from child_servers
inner join Hosts
on child_servers.nIdHost = Hosts.nId;

Current certificate is expected to be not NULL. Otherwise, re-connect secondary server to the primary manually and make sure there is no connectivity issue. 

Example:

Цитата

192.168.1.222    

-----BEGIN CERTIFICATE-----

MIIDvjCCAqagAwIBAgIUJhZfMFZrF0rhoNA+wzPS5tEmj+8wDQYJKoZIhvcNAQEL BQAwHDEaMBgGA1UEAwwRZGMxLmtzY3Rlc3QubG9jYWwwHhcNMjQxMTA2MTIyNTUz WhcNMjUxMjA4MTIyNTUzWjAcMRowGAYDVQQDDBFkYzEua3NjdGVzdC5sb2NhbDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ2sVnYNKWHEDO8HXkKksG9X WComiBWVYgpCwx9/i2yFfKmVgVhnT9Yg3mftgyYdZ2V2udCThC2ZxIkA5B3Dnaw/ RBlrRmhAeak5wQs12qTsbRJhOPcqmaoDDe0FZ0dZ4Dv60QLmS7vbi/AvZ1XLf106 3BHnakanGoBsvjF6Wsrg4BjR17sb3HjUYFWYd3iZ/fT4sWL4VbTYhspXM9VyJw/5 tQfReS2/84l7PA+7wE80fXD3y7K+dGljhp7kUqCUnGBkIq5vPPx8HD6mUCxZCKQB ZAn2w0MhDhTfiCpBuuYh0QWx6TxcMQ/TtSDvgRkfSZ8bMzT9zYw69DMOi9ukeuEC AwEAAaOB9zCB9DAcBgNVHRIEFTATghFkYzEua3NjdGVzdC5sb2NhbDAcBgNVHREE FTATghFkYzEua3NjdGVzdC5sb2NhbDALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFOGf wWoxj924mnaaF10douKwCLMbMFcGA1UdIwRQME6AFOQ5TL+pnURz1fq2pauJMik+ HY1KoSCkHjAcMRowGAYDVQQDDBFkYzEua3NjdGVzdC5sb2NhbIIUKWl0PMtThGoW 2P0wanMPNGlxlUYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEF BQcDAQYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggEBAGBN5qQowGROPlfkTjqJ 59UYhMSEdczMDkaBbeUb0+jzju9GD3rXXBZ47oPcn8Uu/3P1ZqYIXyK2pqTQaxN3 XUW5NPE03KAgBufDHTPUP5jDrjf3b5uUD1OhY20oz1kGODa6eSZG/mlRYfWqTdAb CceQ0GS39/6ZwX0yPrjuaoWh+IbTMuygPEH1AAs4VD55af1E59aOTtwL7s2y04ba 8NiFNAprHZeJtr5u2RUYN/LSVrt8Aze6wyGyG+9U4t/arWIh/VUWTKZk/4QOUIOp exhlRxtNu2S5ud6/TXtsUZ7RK9pzxqaqlbHXCvy01R3vwWRVwi55CFyJJ1hkNuUe UsE=

-----END CERTIFICATE----- 

Please be advised that automatic renewal of secondary server certificate is supported since KSC 14.0. Older versions are not supported.

Known problem:

Problem with Webconsole login - incorrect user or password - see article 

https://forum.kaspersky.com/blogs/entry/331-ksc-web-console-shows-an-error-after-upgrade-incorrect-user-or-password-ksc-for-windows/

Error - Failed to establish connection with the remote device:

This error occurs because we are trying to execute 2 consecutive commands on the same line. The first command is "-t CR -g nb.loc" and the second is "-f '20-12-2023 00:00'". Since the administration server restarts after executing the first command, the second command waits for some timeout before executing. But since in some user configurations, restarting the service can take a long time, the second part is performed when the server has not started yet. Which leads to the above error.

In order to fix this behavior, you need to run the commands separately, according to this scenario:

1. Run .\klsetsrvcert.exe -t CR -g nb.loc
2. Wait until the administration server service starts completely (you can check by connecting the console).
3. Run .\klsetsrvcert.exe -f '20-12-2023 00:00'

What to do - 

1. Generate reserve KSC certificate - for example by using command - 

klsetsrvcert -t CR -g "dns_name" -o "RsaKeyLen:2048"

where DNS name is DNS name of KSC

2. Wait several days - hosts will connect to KSC and receive reserve cert. 

The customer could check on client hosts that cert if received by the command - 

klscflag -ssvget -pv 1103/1.0.0.0 -s KLNAG_SECTION_CERTDATA -n KLNAG_SSL_SERVER_CERT_RESERVE -ss "|ss_type = \"SS_LOCAL_MACHINE\";"

In results - if reserve cert is installed - there will be smthg like - 

+--- (PARAMS_T)

    +---KLNAG_SSL_SERVER_CERT_RESERVE = BINARY_T (size = 2944): 2D2D2D2D2D424547494E2043455254494649434154452D2D2D2D2D0A4D494945627A4343413165674177494241674955616E63416F503772716145594E44376265534D4D47396941716951774451594A4B6F5A496876634E4151454C0A42514177567A455A4D42634741315545417777516347786C61326868626D39324C6D46...

If there is no reserve cert - there will be a message - 

FAILED - 1125 ('Parameter with name "KLNAG_SECTION_CERTDATA" not exist.') 

3. Specify the date and time of next cert change by the command - 

klsetsrvcert -f "DD-MM-YYYY hh:mm"

If you are sure that reserve cert if received already - you can specify the past date in this command - cert will be replaced right after that. Don't forget that if agent didn't receive reserve cert and cert is replaced already - agent will lost connection to KSC server. 

4. Run WebConsole installer and specify new klserver cert there. 

Check the connection in WebConsole.

An attempt to send POST request via KPSN API from a Windows client.:

curl --cert C:\\Users\\user_A\\Desktop\\kpsn_api
kpsn_api_crt.pem --key C:\\Users\\user_A\\Desktop\\kpsn_api
kpsn_api_key.pem -k -X POST -d "{\\"action
": \\"check_url\\",\\"data
": {\\"urls
": [\\"website1.com
"]}}" https://10.90.116.27:80/api/

Fails with the following error:

curl: (58) schannel: Failed to import cert file C:\\Users\\user_A\\Desktop\\kpsn_api
kpsn_api_crt.pem, last error is 0x80092002

There is no such issue when using curl on a Linux client.

Cause

The used version of curl.exe on Windows is not configured to work with OpenSSL.

Solution

Use other tools to send requests, e.g Insomnia or curl from Git for Windows.

Problem

You change the account of the administration server service via the klsrvswch tool. Note that this is the only way to change the account, manual modification (for example, via services.msc) is not supported. 

Then, the you run the Install required updates and fix vulnerabilities task.

As a result, the task is cancelled and updates are not installed. 

Diagnostics

The following error can be found in $klserver-1093.log:

20.11.2023 10:26:16.683 00000ADC.000028C0 L4  KLSTD: Error 0x5 accessing the file 'C:\ProgramData\KasperskyLab\adminkit\1093\.working\FTServer\#WSUS#', m_dwWin32Access=0x80000000, m_dwWin32Creation=0x3, m_dwWin32Flags=0x8000000

20.11.2023 10:26:16.683 00000ADC.000028C0 L1  KLSTD: Error ERROR_ACCESS_DENIED (attempt 186 from 300) for the file 'C:\ProgramData\KasperskyLab\adminkit\1093\.working\FTServer\#WSUS#'

When checking permissions of the file C:\ProgramData\KasperskyLab\adminkit\1093\.working\FTServer\#WSUS#, it lacks the new service account assigned to the kladminserver service:

In this example, the Administration Server account is the old service account used to start the KSC service. 

Workaround

Add the new KSC Service account or the KLAdmins group to the access control list of the #WSUS# file and grant it full access:

In Kaspersky Security Center Network Agent (klnagent) 15.1 and more recent versions, klmover tool requires klnagent uninstallation password to re-connect a managed host to another Administration Server: https://support.kaspersky.com/ksc/15.1/227839
If the password is not set in the policy, it is not required to be specified in command line via the parameter: -nauninstpwd

If klmover is executed directly through a Command Prompt, the parameter will work as expected. However, if klmover is started by a .bat file, the uninstall password cannot be passed to command line properly. 

Solution

echo command

Qwerty12 is the klnagent uninstallation password and 192.168.1.221 is the IP address of KSC Server.

echo Qwerty12|"C:\Program Files (x86)\Kaspersky Lab\NetworkAgent\klmover.exe" -address 192.168.1.221

cmd doesn't parse quotes and spaces in echo properly: If klmover is started from cmd and the password contains characters requiring quotes, klmover should be run from Powershell.

Powershell has a Start-Process command, allowing to run a process as a different user, in this case it can be used in a batch script:

cd "C:\Program Files (x86)\Kaspersky Lab\NetworkAgent\" C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe -Command "Start-Process powershell '-Command echo <password>|.\klmover.exe -address <address>' -Verb RunAs"

Example:

cd "C:\Program Files (x86)\Kaspersky Lab\NetworkAgent\" C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe -Command "Start-Process powershell '-Command echo Qwerty12|.\klmover.exe -address 192.168.1.221' -Verb RunAs"

Text file

Alternative method is to save the password in a text file password.txt 
Remember about the option Copy entire folder to the installation package when uploading the installation package, otherwise, password.txt will not be copied to target hosts.  

"C:\Program Files (x86)\Kaspersky Lab\NetworkAgent\klmover.exe" -address 192.168.1.221 < password.txt

In this case, special symbols in the password can be passed correctly to klmover as command line parameter.

Previous versions of klmover are not compatible with klmover in klnagent 15. 

After the deployment of KSC in the environment, the Backup task fails with the following error using the KSC Backup task or klbackup utility (screenshot is below).

All the permissions were correctly assigned on the shared folder, and ports were opened, but still the backup was failing. There were no blocking events in the Firewall traffic logs.

Error -1963 ('Database connection is broken " 'Connection failure{08S01};' LastStataement='select type from sys.system_object where name = 'dsm_os_host_info';'"

Root cause

The issue was identified to be the IPS module of the Firewall (Fortinet/Paloalto) in the environment. When the backup task was initiated, the IPS module was blocking the SQL backup query with "SMB Injection/Attack" signatures.

Solution

Disable the IPS policy on the Firewall for KSC and MS SQL servers and the backup task will be completed successfully.

The installation of the Network Agent isn't possible on a device because of the error System error 0x1F (A device attached to the system is not functioning.)

Diagnostics

In the MSI Log and Application Eventlog can be found the following line:

(1192/0x0 ("System container 'LOC-PUB-6EEB50F8D2EB46029DB4CCB77E0DA651' is corrupt")

Workaround & Solution

The issue comes from a corrupt cryptostorage in the OS. It's not a KL related issue, although there is a possible solution to fix it.

1. On the problem host launch cmd.exe with administrative privileges
2. Run klcryptstgclean.exe:
    klcryptstgclean -tl 4 -tf $klcryptstgclean_trace.txt -l klcryptstgclean.log
3. Try to install NAgent.
4. If it doesn't help, perform actions from the Cryptostorage-1.docx file.
5. If installation fails again, send to Kaspersky Support the following files: "$klcryptstgclean_trace.txt", "klcryptstgclean.log", new GSI with klnagent installation logs.

Scenario

Administrator tries to install Kaspersky Security Center Network Agent (klnagent).
One of the errors occur: 

In case of standalone package, installation error might be a little different: 

When looking closely to $klnagent-setup* logfile, the following error is found: 

This means there are some remains of the Network Agent in registry that need to be cleared for successful installation.

Troubleshooting steps

Collect data

Export the whole Computer registry branch and provide $kl* install log files. 

Analysis and troubleshooting

1. Make sure $klnagent-setup-<timestamp>.log contains System error 0x648: 

2. Search the registry file for any occurrences of Kaspersky Network Agent or Kaspersky.

Search only at:

• • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer,
  • HKEY_CLASSES_ROOT\Installer 
  • HKEY_CURRENT_USER\Software\Microsoft\Installer

You will find either of:

• [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Managed\S-1-5-21-1971608977-3548673899-3505954282-500\Installer\Products\5E4E50F098A5C284A92674CC85467388]
• [HKEY_CLASSES_ROOT\Installer\Products\42FC4FCBBA881E546A6E048C72A8075C]

3. Go to HKEY_CLASSES_ROOT\Installer\UpgradeCodes and search for 5E4E50F098A5C284A92674CC85467388 or 42FC4FCBBA881E546A6E048C72A8075C

Delete the found registry branches:

• [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Managed\S-1-5-21-1971608977-3548673899-3505954282-500\Installer\UpgradeCodes\5278159B67B039744A906C974424BF05]
• [HKEY_CLASSES_ROOT\Installer\UpgradeCodes\5278159B67B039744A906C974424BF05]

These entries can be in user portion of Windows registry so the search should be performed in the whole registry. It might be that Network Agent removal tool cannot delete entries from registry, this is why this manipulation is required. 

Once all such entries are deleted, Network Agent installation should be successful.

You may experience low time to live value set in ICMP network packets sent by klnagents. 

The following can be seen in wire shark traffic dump:

Explanation:

There are two modes of distribution point search:

0 - search of the nearest DP using a tool similar to traceroute. It generates a number of ICMP packets to find out the neatest route to DP - this is the default mode. 

1 - selection of random DP without sending such amount of ICMP packets. This mode is configured on administration server computer via klcsflag utility and is enabled for all managed hosts.

The following command should be started as administrator on KSC Server computer to switch to mode 1:

Consider the following scenario:

You have a large local area network 10.36.0.0/16. There is a managed device with the following IP config: IPv4 address: 10.36.35.10 and Subnet Mask: 255.255.255.0. You create a new subnet condition for klnagent connection profile: 10.36.0.0/16.

Actual result:

The connection profile is not applied to the managed device.

The reason of this behavior is equality logic used by klnagent. It verifies if the condition matches by comparing the current value of the IP address and subnet mask of a managed device:

IP address 10.36.35.10 is within the 10.36.0.0/16 network.

However, subnet mask 255.255.255.0 is not equal to 255.255.0.0 specified in the condition.

Solution:

In order for the rule to work correctly, each 10.36.0.0/24 subnet (including 10.36.35.0/24) of the larger 10.36.0.0/16 network should be added as a condition:

To do so, follow these steps:

1. Back up the data of Kaspersky Security Center using one of the methods described below:
   1. Backup and Restore Wizard
   2. Backup task
2. Check if you can install Kaspersky Security Center on your current server. For system requirements, see Online Help.
3. Then export the list of currently installed plug-ins in the .csv format.   

1. Download the latest version of Kaspersky Security Center.
2. Install Kaspersky Security Center. For instructions, see Online Help. 
3. If needed, you can restore the Administration Server data. For details, see Online Help.

Important notes

• Make a note of the password configured during the backup process.
• Install Kaspersky Security Center on a new server if your current database server is not supported. Then restore the database data.
• Restoration works between database servers of the same type. If you use an SQL Server as a DBMS, you can migrate data to MySQL or MariaDB DBMS before the upgrade. For details, see Online Help.
• It is possible to restore data from the SQL Express database to the SQL Standard database, but the restoration of data from the SQL Standard database to the SQL Express database is supported with limitations.

For further details, please check this Online Help page.