All Activity

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article is about Kaspersky Endpoint Security for Windows (KES for Windows) Sometimes it is required to unregister KES from context menu of Explorer. Follow these steps: Disable self-defense of KES; Open CMD shell as admin; Run commands: regsvr32 /u C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\x64\shellex.dll regsvr32 /u C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\shellex.dll Process troubleshooting. To re-enable it, run in admin CMD: regsvr32 "C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\x64\shellex.dll" regsvr32 "C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\shellex.dll"

How to upgrade previously installed password protected KEA using KSC remote installation task. Step-by-step guide Edit attached file install_props.json, put there your password for already installed KEA; Put this file to folder on KSC containing files for creation of remote installation package for new KEA version as per screenshots below; Create on KSC package for remote installation; Start remote installation task on KSC.

Most of the time KEA core patches are cumulative and it is sufficient to install the newer one on top of the previous in order to fix new issues. However, sometimes, for troubleshooting purposes or otherwise, you would need to remove an existing patch. This is how it's done. Step-by-step guide In the Administration Console, go to Advanced → Remote installation → Installation packages; In the right frame, click Create installation package; Select Create installation package for specified executable file; Enter the name for the package and click Next; Click Select and specify the path to the MSP file with the patch. The file must be located in the folder with MSP and MSI files of the major application version; In the Executable file command line field enter the following: /i <GUID KEA> MSIPATCHREMOVE={GUID of Core} /qn Example of the path to uninstall KEA 3.9 Core 11: /i {B310DC3B-8C5A-4C9D-A054-DFEEF8549B9B} MSIPATCHREMOVE={3891229E-A660-4416-B662-F5ED41B7B771} /qn GUIDs of KEA msi and Core msp files can be found into properties of these files under Details tab in the Revision Number line Click Next→ Finish; Create a remote installation task with this installation package for a device or a group of devices; Run the task to remove the patch.

Problem Some users may face a rather unclear and not self-explanatory error when attempting to remotely install KEA for Linux: Remote installation has been completed with an error on this device: Installation error Error in PREIN scriptlet in rpm package epagent Error: Transaction failed Solution This error is specific to RHEL-based distributives which have SELinux. KEA for Linux does not support Enforcing SELinux mode, and thus requires SELinux to be either disabled, or set to Permissive mode. To set SELinux to permissive mode for current session(until reboot): setenforce Permissive To disable SELinux, in file /etc/selinux/config set SELINUX=disabled

Problem In some cases, it is possible to run a database upgrade task on the KSWS/KICS/KESS host, but despite the upgrade task successfully completing, the databases are still out of date. Solution Most probably product operates in UpdateBlackListOnly mode. This happens in cases when product is activated with activation code and is unable to reach our activation servers. Thus KSWS fails to receive/refresh activation ticket and downloads updates only for Blacklist. Possible ways to solve the problem: 1. Activate with a key file; 2. In case KSWS needs to be activated with the code make sure that either KSWS server is able to reach our public activation servers directly or set up KSC to act as activation proxy and make sure that KSWS server is able to reach KSC on TCP17000.

As the first step of troubleshooting of KEA, we recommend installing the latest core patch. However, sometimes such installation will fail. There are two popular causes of this: EULA is not accepted; KEA installation is protected with a password. This guide addresses both of these issues. # in Password Symbol Due to limitations in KSC, when creating a custom package for remote deployment in KSC, or editing package configuration file (.kpd) directly, if password contains "#" symbol, it won't work. Examination of saved package shows everything afterwards and including # is lost from command line. This is because in (.kpd) configuration files # is a sign of a single string comment. Thus # is invalid symbol and cannot be used in command line. Behavior is expected from KSC side and cannot be changed. We recommend not to use # in password. Step-by-step guide The following options need to be provided to the installer: disclaimer=1 This instructs the installer to accept the EULA. UNLOCK_PASSWORD=password This is required if the installation of KEA is protected with a password. Replace "password" with the actual value of the password. Local installation The resulting line for local installation may look like this: msiexec /p critical_fix_core9(private).msp disclaimer=1 UNLOCK_PASSWORD=password Remote installation The same options can be used when deploying remotely via KSC. Specify them as follows:

Step-by-step guide KATA 3.7.2 Connect to central node/sensor node which processing SPAN traffic via ssh; Proceed to Technical support mode; Become root with command: Turn on wrapCopy as text # sudo -i Create file /etc/suricata/capture-filter.bpf with line containing traffic filtering conditions (syntax is the same as in tcpdump conditions), below you can see filter for example: Example: Turn on wrapCopy as text # cat /etc/suricata/capture-filter.bpf not ((src 10.21.68.247 and dst 10.21.60.155 or 10.21.60.14 or 10.21.60.15 or 10.21.60.80 or 10.21.60.212 or 10.20.72.48 and port 1433) or (src 10.21.65.113 or 10.20.75.142 and dst 212.250.153.80 or 212.250.153.81 or 194.72.254.216 or 194.72.254.217 and port 22)) Change owner/group for created file with command: Turn on wrapCopy as text # chown kluser:root /etc/suricata/capture-filter.bpf Edit file /usr/bin/apt-suri-start, find line: Turn on wrapCopy as text /sbin/suricata -c /etc/suricata/suricata.yaml $OPTIONS || { And change it to: Turn on wrapCopy as text /sbin/suricata -F /etc/suricata/capture-filter.bpf -c /etc/suricata/suricata.yaml $OPTIONS || { Restart suricata.service with command: Turn on wrapCopy as text # systemctl restart suricata.service Check absence of errors in system journal related to suricata service restart with commands: Turn on wrapCopy as text # systemctl status suricata.service # journalctl -u suricata.service Done! KATA 5+ Connect to central node/sensor node which processing SPAN traffic via ssh; Proceed to Technical support mode; Become root with command: Turn on wrapCopy as text sudo -i Run the following command, replacing it with your rule with your rule in tcpdump syntax, for example "not ((src 10.10.0.1 or src 10.10.0.13 or src 10.10.0.11 or src 10.10.0.14) and (dst 10.10.6.13 or dst 10.10.6.11 or dst 10.10.6.12))":n on wrapCopy as text console-settings-updater set --merge /kata/configuration/product/preprocessor_span '{"traffic": {"storage_settings": {"bpf_filter": "your rule"}}}'

Problem There are slight differences when connecting devices to the Wi-Fi network configured via Kaspersky Endpoint Security for Mobile in Android 10. The main difference is that the connection to the target Wi-Fi network is made automatically through the product installed on the device and can't be forced manually via device settings. Step-by-step description The following scenario demonstrates the correct way to connect the device to a Wi-Fi network, as well as what behavior is expected. Setting up the target Wi-Fi network in the Kaspersky Endpoint Security for Android as usual – navigate to Wi-Fi section and add new network by specifying network SSID, network protection type and password: Apply the configured policy to the target mobile device with KESM installed and Android 10 (sync the product with the Security Center); When the policy applies, "Allow suggested Wi-Fi networks" notification from Android System appears (unless the mobile phone is located in the target Wi-Fi access zone): The user should open this notification and tap on ‘Allow’ / 'Yes' link. It should be done only once, when a new one network is added through the product; Depending on the conditions: If the target mobile device is not connected to any Wi-Fi networks, then the connection to the expected network is made immediately automatically (no further actions are required from the user); If the target mobile device is already connected to another Wi-Fi network (and it was made manually by the device owner via native mobile phone network settings), then the connection to the expected network will not be made until the user manually disconnects his device from the current Wi-Fi network ('forgets' this network). As soon as this happens, the device will automatically connect to the desired network configured through the product. If everything works as expected, then you’ll find an inscription near the network: ‘Connected via Kaspersky Endpoint Security’: Please note that if the device is still connected to another Wi-Fi network (which was added manually before) and the client just tries to connect to the target network configured through the product on his own (navigates to the ‘Network and Internet’ section – finds there the target network and taps on ‘Connect’ link), then it will be not possible to do that: connection settings from the product's policy will not be pushed and the password will be still required (obviously, if this network is protected by password): The connection will be established automatically as soon as the device owner disconnects their mobile phone / tablet from the previously used network on his own (applicable to the networks that were connected manually via device settings).

Description As part of proactive security, you may wish to add sha256 to block the execution of application or malicious applications without having the original source files. This article explains how to perform this action. How To Create a text file containing the sha256 you want to block. Use the AppRulesGenerator.exe app to generate an xml file: Import the generated .xml file into the KSWS policy: AppRulesGenerator.exe can be downloaded here.

Description After successful installation kesl-supervisor.service may refuse to start with the following error: kesl-supervisor.service: Control process exited, code=exited status=203 journalctl -xe command provide more information related this error ***** kesl-supervisor.service: Failed to execute command: Permission denied kesl-supervisor.service: Failed at step EXEC spawning /var/opt/kaspersky/kesl/install-current/etc/init.d/kesl-supervisor: ***** kesl-supervisor.service: Control process exited, code=exited status=203 kesl-supervisor.service: Failed with result 'exit-code'. Failed to start kesl. Root cause SElinux is enabled on the system and prohibits execution of the service. Solution You can check SELinux status by running: $ sestatus If SELinux is enabled, then use the dedicated online help article to disable, configure and re-enable it.

Sometimes one may need to enable transmitted traffic capturing in KATA (in example, for local testing of Suricata detections). Here's how to do it. Instructions for KATA 3.7.* In file /etc/modprobe.d/pf_ring.conf set enable_tx_capture=1. File should look like this: options pf_ring enable_tx_capture=1 min_num_slots=16384 Stop apt-preprocessor and suricata services: systemctl stop apt-preprocessor.service systemctl stop suricata.service Reload pf_ring module: rmmod pf_ring modprobe pf_ring Start apt-preprocessor and suricata back systemctl start apt-preprocessor.service systemctl start suricata.service Instructions for KATA 4.0/4.1 In file /etc/modprobe.d/pf_ring.conf set enable_tx_capture=1. File should look like this: options pf_ring enable_tx_capture=1 min_num_slots=16384 Stop docker service: systemctl stop docker Reload pf_ring module: rmmod pf_ring modprobe pf_ring Start docker back systemctl start docker Instructions for KATA 5.0 In file /etc/pf_ring/pf_ring.conf set enable_tx_capture=1. File should look like this: options pf_ring enable_tx_capture=1 min_num_slots=16384 Stop docker service: systemctl stop docker Reload pf_ring module: rmmod pf_ring modprobe pf_ring Start docker back systemctl start docker With these changes, KATA will capture and process both incoming and outgoing traffic.

Problem Sometimes it is necessary to replace the KSN proxy address in products like KSWS, KESS or KES after restoring KSC from backup or when Server moved to new Hardware. Unfortunately, there are no settings in the policy for this. Solution The corresponding option can be found in the properties of Installation packages node in KSC. See the effects of changing this value: Note that after changing these settings, you must also rebuild the Network Agent installation packages, even if the change is propagated to connected clients.

Все равно ситуация очень и очень странная, раньше не выдавало и тут вдруг с новой версией стало выдавать. Тоже Adguard пользуюсь и ниразу проблем с Касперский не было. Тоже склоняюсь, что попытка продвинуть свой блокировщик, который откровенно говоря работает не очень. В подсказке в приложении выдает, что якобы какие-то функции защиты не будут доступны в такой связке. Вот тут и напрашивается какие именно???

Problem In some cases KESMac is not able to start protection components: Or, the status "Allow encrypted traffic to be inspected" is not changing: Solution 1) Please get acquainted with the article https://support.kaspersky.com/kis20mac/error/15031#block1; 2) If the article above did not help, try to remove the FireFox user's profiles directory via Terminal: rm -rf ~/Library/Application\ Support/Firefox/Profiles Removal of the Firefox profiles deletes the user's data stored in the browser, like saved logins and passwords, visited websites and other. Make backup if needed. Then, reboot the host and check the issue reproduction.

The KESMac 12 and the KESMac 11.3 patch C allows adding particular processes into the trusted section named Trusted Applications. The both filesystem and network activity of which can be ignored by the product increasing performance. Please, however, note that this could be potentially risky. https://support.kaspersky.com/KESMac/11.3_adminguide/en-US/194142.htm Problem This article will describe a few ways to configure KES for Mac to exclude some of the software from the scope of the product. Solution Trusted applications In order to have an ability to exсlude an application from scanning with KES, a function of Trusted Applications available in Kaspersky Endpoint Security for Mac can be used: The Trusted applications section as seen in the policy creation wizard. Naturally, it can be configured later by modifying the policy. Update the plugin to at least version 11.3.0.33 to get the new functionality. In some specific cases it might be required to put several binaries to Trusted Applications simultaneously in order to take effect. So, a final solution might include several path-based exclusions accompanied by a few BundleID-based ones. Trusted Applications are only available for configuration via KSC policy; i.e. it is currently impossible to add application to exclusions having no KSC installed. Additionally, an appropriate application control plug-in for KESMac must be downloaded and installed on the KSC prior to using Trusted Application functionality. It can be found on the corresponding download page. Common exclusions for developers It's suggested excluding the following paths: "/Library/Developer/CommandLineTools" and "/Library/Toolchains" for the standard developers' utilities, as well as the "/Applications/Xcode.app/*" for the XCode. At the same time, in case you use alternative tools, contact Kaspersky Support to get the exact paths for further exclusions. Excluding TCP 443 from port monitoring Additionally, in case of HTTPS-connectivity issues, unchecking port 443 in Monitored ports may also help:

Article applies to KSC13-14.2 versions. Sometimes you need to keep KSC tracing on for a long period of time to catch the error and there is little disk space left on the system disk. Step-by-step guide There is a way to change the default location of $klserver-1093.log file - use klscflag.exe utility" klscflag.exe -tset -pv "klserver" -l 4 -d O:\Temp O:\temp can be changed to any existing folder name in file system. Remember to create this folder before running the command. In order to revert trace file location to default value, delete the value TraceDir from HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\Components\34\1093\1.0.0.0\Debug: Same applies to klnagent trace - custom settings should be written to the following registry branch: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\Components\34\1103\1.0.0.0\Debug] Additional option: TraceMaxSizeMB is an optional value that enables trace files rotation for all services of the Kaspersky Security Center. The value of it variable determines the total size of trace files in MB. The absence of the variable or its zero value means that rotation is disabled. Maximum variable value is 102400 (0x19000), which means 100 GB. Example of reg file: REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\KasperskyLab\Components\34\1093\1.0.0.0\Debug] "TraceDir"="O:\\Temp" "TraceLevel"=dword:00000004 "TraceMaxSizeMB"=dword:00002000 In this example, trace files rotation is enabled and total trace file size of 8192 MB (8 GB). Logs will be saved to O:\temp. Note: in KSC14, klscflag.exe utility can be found in KSC installation folder, no need to copy the tool.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Article applies to KSC13-14.2 Consider the following scenario: Open KSC MMC console; Go to Kaspersky licenses; Select KSC license. Devices on which the license key is active is zero regardless of fact that this key is assigned as active on KSC Server: Explanation In older versions of Kaspersky applications, several license key files were provided to activate different products - one for KSC - 1 license unit and another for workstations and servers (Kaspersky Security for WS and FS) - in this example, 150 license units. In this example, 151 license units. In newer versions of Kaspersky applications, an activation code is provided (activation 2.0 format). When you activate an application with this activation code, total number of license unit is 150, this is 1 fewer than 151 because KSC Server consumed 1 license. Solution The license for KSC server is not counted. This applies only to activations codes. Re-configure Report on usage of license keys to display all summary fields; Re-generate the report - it will display KSC license as active on KSC Server: Open the properties of KSC server→License keys to make sure it is activated with a valid license.

This article applies to Endpoint Agent for Linux. To collect LENA debug or ANY traces, please follow this guide. Default traces location is '/var/log/kaspersky/epagent/'. Default dumps location is '/tmp/agentdumps' Public collect.sh script was updated to collect LENA-related information and gather these folder as well. How to: enable LENA ANY traces For KATA-EDR (on-premises) customers to tune LENA performance by exclusions, ANY level logs are required. To enable ANY logging: Become root sudo su - Use one-liner to enable ANY tracing level: sed -i 's/LENA_TRACE_LEVEL=none/LENA_TRACE_LEVEL=any/g' /etc/opt/kaspersky/epagent/service.conf && systemctl restart epagent Modify the config file /etc/opt/kaspersky/epagent/service.conf /etc/opt/kaspersky/epagent/service.conf KESL_FIFO_PATH=/run/log/kesl-messages AUDIT_FIFO_PATH=/run/log/audit-messages LENA_TRACE_LEVEL=none <-- set any here instead of none LENA_DUMPS=yes Save the modided value. Careful, CaSe sensitive values! LENA_TRACE_LEVEL=any ← correct LENA_TRACE_LEVEL=none ← correct LENA_TRACE_LEVEL=ANY ← wrong LENA_TRACE_LEVEL=None ← wrong To apply changes, restart epagent service systemctl restart epagent Wait until the problematic behavior is reproduced; Stop traces /opt/kaspersky/epagent/sbin/lenactl --traces --off Double-check that produced traces indeed contain ANY-level information use this command: grep -q ANY /var/log/kaspersky/epagent/lena*; if [[ $? == 0 ]]; then echo "ANY logs"; else echo "Not ANY :("; fi As an addition you can check for how long ANY traces were gathered like grep -h ANY /var/log/kaspersky/epagent/lena* | awk '{print $1}' | cut -d '.' -f 1 | uniq And as final accord you can check whether you gathered enough ANY traces to be analyzed and sneak-peek what processes are producing excess load grep -ha "from auditd" /var/log/kaspersky/epagent/lena* | grep -oE "\"exe\"\:\[\"[^\"]+\"" | sort | uniq -c | sort -nr | sed -e 's/$/\]/' | grep -E "[0-9]{3,}\s+\"" Collect the produced logs and system information in one go using collect.sh script How to: enable LENA debug traces Debug traces take less space and are suitable for troubleshooting issues not-related to Performance or 3rd party compatibility. Enable debug traces: /opt/kaspersky/epagent/sbin/lenactl --traces --on This method is not suitable for ANY traces and will override ANY traces level set previously by DEBUG value Wait for a while until the problematic behavior is reproduced; Disable traces: /opt/kaspersky/epagent/sbin/lenactl --traces --off Collect the produced logs and system information in one go using collect.sh script How to: enable LENA log rotation To add log rotation, add to /etc/opt/kaspersky/epagent/service.conf following strings: /etc/opt/kaspersky/epagent/service.conf LENA_ROTATION_COUNT=10 <-- set max number of log files LENA_ROTATION_FILE_SIZE=100m <-- set the size of each file To apply changes, restart epagent service systemctl restart epagent

Problem Messaged are delayed for 50 minutes and in /var/log/maillog there are following entries: Dec 10 12:07:07 ksmg KSMG: put to asp quarantine: message-id="": relay-ip="10.10.1.1": action="Postponed": size=21958: mail-from="test@example2.com": rcpt-to="test@example.com" Solution This is a a feature which delays some suspicious messages for 50 minutes (by default) and then rescan them with newer bases and information in KSN. This can be turned off in Settings -> Protection -> Anti-Spam -> Use reputation filtering. The delay can be tweaked in Settings -> Protection -> Anti-Spam Quarantine. Delayed (quarantined) messages are visible in Message Queue section of KSMG and can be forced to be delivered from there with 'Flush' button. Which messages to delay or not to delay can be tweaked with bases, so if you get messages that are delayed but shouldn't, then please provide message samples to Kaspersky Support for investigation as 'false positives'. For KSMG 2.0 (Use Anti-Spam Quarantine and Maximum Quarantine duration options accordingly):

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Problem There is no mechanism to replace client root certificate used for iOS MDM via reserve certificate. That's why replacing the client root certificate used for iOS MDM will cause iOS MDM server to lose synchronization with all devices. Details of active certificate can be viewed in the properties of iOS MDM server, on the "Certificates' tab. Step-by-step guide The iOS MSM Server Client Root certificate replacement procedure includes the following steps: Backup iOS MDM Server configuration via kliosbackup utility: kliosbackup -backup(-restore) -path BACKUP_PATH [-pwd PASSWORD] Backup Kaspersky Security Center configuration via klbackup utility or ‘Backup of Administration Server data’ task; Create a new certificate in the PKCS#12 format using the PKI infrastructure; Submit the certificate to the input of the klsetsrvcert tool just the same way as it is described in the corresponding Kaspersky Security Center versions online help articles (for example, for KSC 14.2: https://support.kaspersky.com/KSC/14.2/en-US/227838.htm? klsetsrvcert -t MCA {-i <inputfile> [-p <password>] | -g <dnsname>} [-l <logfile>]. These actions will update the iOS MSM Server Client Root certificate, you may check C:\ProgramData\KasperskyLab\adminkit\1093\cert\klsrvmdm.cer to make sure that a new one certificate has been installed. Recommendations: Validity: up to 5 years Key length: 4096 bits (2048 bits is also possible, but for a five-year certificate it is still better to use 4096) Setting the EKU (Extended Key Usage) for this certificate in Client Authentication Automatic replacement of the client root certificate used for iOS MDM and issued through Administration server tools has been implemented since KSC 12.2 and higher.

Problem You may encounter issues with KEA that may include: Excessive resource consumption Freezes, crashes etc. Solution Install the latest available core patch. Adding KEA CF to KEA installation package is not supported and will not work, patches need to be installed separately. To install patch using KSC or locally use the following keys, /qn can be added for silent install as usual How to install patch msiexec /p private_critical_fix_99.msp DISCLAIMER=1 EULA=1 PRIVACYPOLICY=1 When installing on servers it is advisable to use additional SERVERPROFILE=1 key for optimized performance (works for core patches starting from CF8 for KEA 3.12 and newer) Additional recommended key for Server installations: msiexec /p private_critical_fix_99.msp DISCLAIMER=1 EULA=1 PRIVACYPOLICY=1 SERVERPROFILE=1 For password-protected installations additional key is needed: UNLOCK_PASSWORD=password For detailed info see article https://forum.kaspersky.com/topic/how-to-install-patches-on-password-protected-kea-kaspersky-endpoint-agent-38148/ Things to keep in mind: All Core patches are cumulative; That means all previous fixes are included. Newer KEA versions include fixes done in previous versions. It's not always necessary to keep KEA at latest core, but it's worth starting your troubleshooting with installing the latest one.

Kaspersky Endpoint Agent, as many other products, has a few different ways of enabling traces. Traces folder NB! The folder specified for traces must exist and be writable. KEA will neither create folder nor display any error if it doesn't exist. One may choose which is best suitable for their needs: Traces with restart In 99% cases, information that is written only during initialization, that is, after KEA restart, is critical for investigation. Unless specified otherwise, always perform KEA restart when collecting traces (after traces are enabled), either by restarting KEA service , via services.msc In some cases, Kaspersky Support Engineer may ask to perform the restart after the reproduction, in that case, restart KEA not after starting traces, but 2 minutes before stopping traces. or using CLI: Elevated cmd (as Admin) sc restart soyuz Verification: traces with restart will always contain the lines with the below text: Traces with restart kata. codeinjection.rule If the text is nowhere to be found, traces are collected without restart and are of zero to no use, such traces need to be recollected following the procedure. Using the agent.exe utility When working with KEA on local host, use cmd or Powershell, started as Administrator, however in some cases KEA installation folder is restricted and requires Local System account to be accessed (one can use Windows Scheduler or, if approved, psexec tool to execute command under Local System). To enable KEA traces: C:\Program Files (x86)\Kaspersky Lab\Endpoint Agent>agent.exe --trace enable --folder C:\path\to\folder To disable traces: C:\Program Files (x86)\Kaspersky Lab\Endpoint Agent>agent.exe --trace disable Modifying registry key Traces This option is specifically useful when you have troubles starting KEA service. Modify the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\SOYUZ\4.0\Trace\Configuration For your convenience, there's also a registry key with example of Debug configuration next to this one: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\SOYUZ\4.0\Trace\Configuration(Example) logging=on;layout=basic;sub-system=*;sink=folder(c:\traces\);level=debug;roll=51200 Notice that in this example traces folder is configured to be c:\traces\. As previously mentioned, the folder specified for traces must exist and be writable so if you decide to use this configuration "as is" you need to create c:\traces folder manually. To disable traces, restore original content of the registry key (logging=off? Disable traces HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\SOYUZ\4.0\Trace\Configuration logging=off Dumps Enable dumps HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\SOYUZ\4.0\CrashDump "Enable"=dword:00000001 "Folder"="c:\\traces\\" "Enable(Example)"=dword:00000001 "Folder(Example)"="c:\\traces\\" Notice that in this example dump folder is configured to be c:\traces\. This folder must exist and be writable so if you decide to use this configuration "as is" you need to create c:\traces folder manually. To disable traces, restore original content of the registry key: Disable dumps HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\SOYUZ\4.0\CrashDump "Enable"=dword:00000000 Using KSC console Enabling traces and dumps Execute the following steps: In the properties of target host in KSC console, locate Endpoint Agent app Open Properties of Endpoint Agent, and navigate to Troubleshooting tab and enable traces and dumps(if needed). NB! It's recommended to write traces to C:\ProgramData\Kaspersky Lab\ folder! To be able to retrieve the traces using Remote Diagnostics Utility configure the traces folder to be the same as respective EPP traces folder, e.g.: For KES %ProgramData%\Kaspersky Lab\KES\Traces For KSWS %programfiles(x86)%\Kaspersky Lab\Kaspersky Security for Windows Server\~TraceFiles Retrieving traces To download files remotely, execute the following steps: Connect to target host with Remote Diagnostics Utility Navigate to KES Trace files folder: Locate soyuz_*.log, proton_*.log, klnagent_*.log - these are Endpoint Agent trace files: Download these files using the 'Download' button. Enabling traces from installation https://forum.kaspersky.com/topic/how-to-enable-kea-traces-from-installation-kaspersky-endpoint-agent-38143/

Problem OAuth consent validation algorithm is the same for Exchange online, OneDrive and SharePoint online. Initial steps of consent validation algorithm are basically the following: A user is redirected to the Microsoft website, where the user agrees to provide necessary permissions for our Azure application. KS365 receives an OAuth callback confirming that the consent was received. But we do not trust this callback as it can be forged. The user is redirected to the Microsoft website to receive an access token that will be used for the validation of the user authenticity. KS365 receives the callback with the access token. After that, the user is redirected to the KS365 website, where the user's session will be started. Step-by-step guide When the user is redirected back to our website on the 4th step, they can encounter the HTTP 401 error: In theory, the user should have successfully authorized as all the necessary data is stored in the browser cookies. Thus, the issue must be on the user's browser side. In such cases, we recommend to attempt the following: Try to add the integration with Exchange Online/Sharepoint Online/OneDrive in a different browser (or even try a different host with different browser versions/settings). Check browser settings related to cookies: if they are supported/enabled, try disabling auto-delete of cookies if it is enabled, etc.

To use HAProxy as a load balancer in front of KWTS (iso installation and built-in proxy used) we recommend the following: HAProxy configuration: global log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4000 user haproxy group haproxy daemon stats socket /var/lib/haproxy/stats defaults mode tcp log global retries 3 timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s maxconn 30000 frontend kwts_proxy bind *:3128 mode tcp default_backend kwts_proxy_pool backend kwts_proxy_pool balance leastconn mode tcp server kwts_node1 10.10.1.42:3128 check send-proxy server kwts_node2 10.10.1.43:3128 check send-proxy where 10.10.1.42 and 10.10.1.43 are KWTS IP addresses; 3128 is the port where KWTS built-in proxy is listening (Settings → Built-in proxy server → Common → Port); 8080 is the port of the load balancer. Configure KWTS to use PROXY protocol header (Settings → Built-in proxy server → Common → Load balancing → Mode); Make sure HAProxy IP address is in trusted list on KWTS (Settings → Built-in proxy server → Common → Load balancing → Trusted load balancers); If Kerberos proxy authentication is used, make sure keytab contains SPN record of FQDN address of the load balancer; Make sure that browser is configured to use FQDN and port of load balancer.

KATA / EDR is using only one certificate for all connections (like WebServer and Client Connections). When you plan to replace it, do it in an early stage of deployment. If you want to replace the TLS certificate, you will need to: Reauthorize mail sensors (KSMG, KLMS) on Central Node. Reconfigure connection of Central Node, PCN and SCN to Sandbox. Reconfigure Endpoint Agent traffic redirection to Sensor and trusted connection with Endpoint Agent. Upload a new certificate in Active Directory (if you use it in Active Directory). Prepared TLS certificate must satisfy the following requirements: The file must contain the certificate itself and a private encryption key for the connection. To generate a pem from your PKI PFX you can use the following command: openssl pkcs12 -in mySecureCertificate.pfx -out kata.pem -nodes The file must be in PEM format. The private key length must be 2048 bits or longer. After replacing the certificate don't forget to replace it in KEA Policy → KATA Integration → KATA Integration Settings → Add new TLS certificate (not the Add Client certificate). The certificate you specify needs to be in CRT Format. You can get it by "Downloading" the Certificate from CN → Settings → General Settings → Download.