Transport level error while connecting kaspersky

Transport level error while connecting kaspersky

Поддержка продуктов для бизнеса

Kaspersky Security Center 11

Почему Агент администрирования не подключается к Серверу администрирования

Статья относится к:

• Kaspersky Security Center 13.2 (версия 13.2.0.1511);
• Kaspersky Security Center 13.1 (версия 13.1.0.8324);
• Kaspersky Security Center 13 (версия 13.0.0.11247);
• Kaspersky Security Center 12 (версия 12.0.0.7734);
• Kaspersky Security Center 11 (версия 11.0.0.1131b).

Связь между Агентом администрирования и Сервером администрирования отсутствует, если:

• На клиентских компьютерах не происходит применение политик.
• Не проходит ручная синхронизация с клиентским компьютером.
• Иконка клиентского компьютера в Консоли администрирования «бледная».
• Значение в поле Соединение с сервером не отражает текущую дату и время (если рабочая станция в сети).

Чтобы провести анализ соединения Агента администрирования с Сервером администрирования, воспользуйтесь утилитой klnagchk.exe:

1. Запустите утилиту с правами локального администратора на проблемном клиентском компьютере из папки Агента администрирования C:Program FilesKaspersky LabNetworkAgentklnagchk.exe.
2. Задайте вывод результатов работы в файл отчета.

Причины, по которым соединение не устанавливается

• Агент администрирования не установлен на клиентском компьютере.
• Агент администрирования был установлен на клиентском компьютере локально и при его установке был неверно задан адрес или порт Сервера администрирования.
• Kaspersky Network Agent не запущен на клиентском компьютере.
• Сервис Сервер администрирования Kaspersky Security Center не запущен на Сервере администрирования.
• В сети имеется несколько рабочих станций с одинаковым именем, в группу ошибочно добавили одноименную рабочую станцию. C помощью поиска (команда Найти компьютер в контекстном меню Сервера администрирования) найдите одноименные компьютеры — введите название компьютера и *. Например, COMPUTER*.
• Клиентский компьютер уже подключен к другому Серверу администрирования данной Windows-сети.
• Клиентский компьютер в данный момент выключен.
• Компьютер-Сервер администрирования не доступен с клиентского компьютера.
  Для проверки воспользуйтесь командой ping на клиентском компьютере.
• На компьютере с Сервером администрирования закрыты TCP-порты 13000, 14000.
• На клиентском компьютере закрыт UDP-порт 15000.
• Имя или IP-адрес Сервера администрирования неправильно воспроизводятся на клиентском компьютере (имя и IP-адрес Сервера не соответствуют друг другу).
• В свойствах политики Агента администрирования на вкладке Сеть настройте подключение к Серверу администрирования и Профили соединений (если они используются).

Утилиты для проверки портов

• Чтобы проверить, что Сервер администрирования открывает порт 13000 или 14000 (имя процесса Сервера администрирования — klserver) запустите утилиту fport.exe на компьютере с Сервером администрирования.
• Если утилита fport.exe не отобразила список открытых портов (например, она не поддерживает Microsoft Windows 2003 Server), выполните команду netstat:

• Выполните команду telnet с проблемного компьютера:

Если команда telnet выдала ошибку, это означает, что порты закрыты.

Источник

Transport level error while connecting kaspersky

Support for Business Products

Kaspersky Endpoint Security Cloud

SSL certificate authentication error when connecting to Kaspersky Endpoint Security Cloud

Issue

Connection to Kaspersky Endpoint Security Cloud fails after installing the Network Agent. When checking the connection logs using the klnagchk utility, the following error occurs: “Attempting to connect to Administration Server. Transport level error has occurred while connecting to http://*.cloud.kaspersky.com/*:13000: SSL authentication failure, the certificate is invalid or outdated.”

Cause

The SSL certificate of the Administration Server is outdated.

Solution

1. Uninstall Kaspersky Endpoint Security for Windows. See the Online Help page for instructions.
2. Create a new Kaspersky Endpoint Security for Windows installation package in Kaspersky Endpoint Security Cloud:

a. Select the Distribution packages section.

b. Click next to the required package and select your language.

c. Carefully read the End User License Agreements for Kaspersky Endpoint Security for Windows. If you agree with the terms and conditions, select the corresponding checkboxes and click I accept the terms.

• The installation package with the updated SSL certificate will be created.

1. Click Download and install the application on your computer.

1. Make sure that you managed to connect to Kaspersky Endpoint Security Cloud and then install the downloaded package on the other managed computers.

What to do if the issue persists

If the issue persists, submit a request to Kaspersky technical support via Kaspersky CompanyAccount. Please include a detailed description of the issue. Before contacting the support, see the guide on creating a request in the Knowledge Base.

Checking the logs using the klnagchk utility

To check the connection logs using the klnagchk utility, proceed as follows:

Источник

[РЕШЕНО] При установке касперского — неизвестная ошибка

Автор yourlife,
16 декабря, 2021 в Помощь в удалении вирусов

Рекомендуемые сообщения

Похожий контент

День добрый !
При активации KSC вылез ошибочный ключ (см. аттач). Кто с такой проблемой сталкивался? Как это вылечить?

Сами выставляются DNS сервера. Началось, как я думаю, после взлома офиса KMSом, DrWeb, Kaspersky и Защитник Windows ничего не находят. В HackJackThis нашел эти адреса, но после удаления они появляются снова. Пробовал сбрасывать TCP IP, переустанавливать драйвера, не помогает. При подключении напрямую к компьютеру интернета, а не через роутер DNS сервера сами не устанавливаются, но проблема не исчезает, и в HackJackThis продолжают появляться после удаления.

Коллеги, доброго дня!

Выполнил восстановление бэкапа. Не могу подключиться к KSC
Будьте добры, подскажите, чем может быть вызвана ошибка?

Источник

Transport level error while connecting kaspersky

При подключении к Kaspersky Security Center вы можете столкнуться с ошибкой «Не удалось подключиться к Серверу администрирования по причине: «Не удалось установить соединение с удаленным устройством (местонахождение: ‘ ‘): отказ в соединении.»».

Решение

1. Запустите Event Viewer на проблемном компьютере.
2. Перейдите в Applications and Services Logs → Kaspersky Event Log.

1. Нажмите Filter Current Log, установите флажки напротив Critical, Warning и Error и нажмите ОК.

1. Появится список проблем, в которых указана причина возникновения ошибки. В зависимости от проблемы, воспользуйтесь решением из таблицы ниже:

Сообщения указывают на неожиданное завершение работы сервера, проблемы с системой или средой. Чтобы исправить проблему:

1. Создайте резервную копию данных Сервера администрирования с помощью утилиты klbackup. Инструкция в справке.
2. Удалите Kaspersky Security Center и его компоненты. Инструкция в справке.
3. Повторно загрузите и установите Kaspersky Security Center. Инструкция в справке.
4. Восстановите резервную копию данных Сервера администрирования.

Что делать, если решение не помогло

Если проблему не удалось устранить, отправьте запрос с подробным описанием ситуации в техническую поддержку «Лаборатории Касперского» через Kaspersky CompanyAccount. Перед обращением ознакомьтесь с информацией, необходимой для создания запроса, в разделе базы знаний.

Источник

Kaspersky для виртуальных сред

Рекомендуемые сообщения

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Похожий контент

Привет. Пытаюсь перекатиться с NSX-v на NSX-t
Действую по инструкциям:
https://support.kaspersky.ru/15667 https://support.kaspersky.com/help/ksv/6.1/ru-RU/90476.htm И в самом конце получаю интересную картину: все инстансы развернуты, имеют Deployment Status — Up, но Health Status — Down

На гипервизорах ESXi в syslog видно, что ВМ не достукиваются до второго интерфейса SVM-ок (который vmservice-vshield-pg):

2022-05-30T14:09:29.849Z ContextMux[18188493]: [WARNING] (EPSEC) [18188493] SolutionHandler[0xdfd0f0e910] failed to connect to solution[7498071167106809856] at [169.254.1.60:48651]: Connection refused (111) for guest[5025611f-c712-4107-2939-b3f96ccfd63d : /vmfs/volumes/627258e3-cd54d7d9-0785-e43d1a9863de/vdi-0051/vdi-0051.vmx] 2022-05-30T14:09:29.849Z ContextMux[18188493]: [ERROR] (EPSEC) [18188493] Solution[7498071167106809856] entry not found in the map when trying to disconnect 2022-05-30T14:09:29.849Z ContextMux[18188493]: [ERROR] (EPSEC) [18188493] Entry not found in map for Solution[7498071167106809856] 2022-05-30T14:09:29.849Z ContextMux[18188493]: [WARNING] (EPSEC) [18188493] SolutionHandler[0xdfd0f0e910] scheduling reconnect to solution[7498071167106809856] at 169.254.1.60:48651 in 30000 ms for guest[5025611f-c712-4107-2939-b3f96ccfd63d : /vmfs/volumes/627258e3-cd54d7d9-0785-e43d1a9863de/vdi-0051/vdi-0051.vmx]
Пинг проходит, netcat — нет:

[root@hv-esxi005p:] ping 169.254.1.60 PING 169.254.1.60 (169.254.1.60): 56 data bytes 64 bytes from 169.254.1.60: icmp_seq=0 ttl=64 time=0.159 ms 64 bytes from 169.254.1.60: icmp_seq=1 ttl=64 time=0.129 ms
[root@hv-esxi005p:] nc -zv 169.254.1.60 48651 nc: connect to 169.254.1.60 port 48651 (tcp) failed: Connection refused
Если открыть SVM через консоль vSphere, видно, что у них даже системного имени не появилось, просто localhost

Вход под рутом, который указывался при регистрации службы на стороне KSC также не доступен. То есть всё это похоже на то, что настройка инстансов не завершилась. Но при этом Deployment Status — Up 🤷‍♂️

Единственное, что смутило, в инструкции есть такой момент по настройке сетевых параметров разворачиваемых инстансов

Но в моем случае чекбокс возле eth1 серый и не выбирается. Но интерфейс и vmk при этом успешно создаются. Предположил, что это неточность инструкции и «System Configured» интерфейс самонастраивается

Здравствуйте. При развертывании SVM на гипервизорах hyper-v (которые являются узлами кластера), возникает проблема при добавлении гипервизоров (Вложение «Ошибка SVM»

cluster_cspn.cspn.orb.ru доменное имя кластера. Причем пинингуется данный хост имя со всех серверов участвующих в развертывании сервера защиты SVM. Гипервизоры имеют другое имя и также пингингуются и доступны для удаленного подключения.

Согласно инструкции были даны права доменному администратору
«Гипервизор Microsoft Windows Server (Hyper-V)
Для развертывания, удаления и изменения конфигурации SVM на гипервизоре Microsoft Windows Server (Hyper-V) требуется встроенная учетная запись локального администратора или доменная учетная запись, входящая в группу Администраторы Hyper-V. В случае доменной учетной записи вам также требуется выдать права на удаленное подключение и использование следующих пространств имен WMI:
rootcimv2;

rootMSCluster;
rootvirtualization;
rootvirtualizationv2 (для версий операционных систем Microsoft Windows для серверов, начиная с версии Windows Server 2012 R2).»

P.S.: Дополнительно сообщаю что сервер защиты SVM 4.0 функционирует в нормальном режиме

Сообщение от модератора Elly Тема перемещена

Источник

Как это ни странно, я нашёл на Хабре всего одну статью по данной тематике — и ту в песочнице и сильно незаконченную фактически содержащую в себе маленький кусочек чуть переделанной справки по продукту. Да и Google по запросу klakaut молчит.

Я не собираюсь рассказывать, как администрировать иерархию Kaspersky Security Center (далее по тексту KSC) из командной строки — мне это пока не понадобилось ни разу. Просто хочу поделиться некоторыми соображениями по поводу средств автоматизации с теми, кому это может понадобиться, и разберу один кейс, с которым мне пришлось столкнуться. Если тебе, читатель, эта тема будет интересной — добро пожаловать под кат.

Исторически сложилось так, что в качестве средства антивирусной защиты на работе я предпочитаю продукты Лаборатории Касперского (далее ЛК). Причины и прочие священные войны личных мнений, пожалуй, оставим за кадром.

Естественно, хотелось бы централизованно развернуть, защитить, оградить и не пущать рисовать красивые графики, интегрироваться в существующие системы мониторинга и заниматься прочим перекладыванием работы с больной головы на здоровый сервер. И если с развёртыванием и защитой тут всё более или менее в порядке (у ЛК даже есть какие-то онлайн-курсы по продуктам), то с интеграцией уже сильно грустнее: в последней на текущий момент версии KSC 10.2.434 появилась интеграция аж с двумя SIEM: Arcsight и Qradar. На этом всё.

Для интеграции в что-то своё KSC предоставляет аж 2 интерфейса:

• klakdb: в БД KSC есть ряд представлений с именами, начинающимися на «v_akpub_», из которых можно достать какую-то информацию о состоянии антивирусной защиты.
• klakaut: DCOM-объект, позволяющий скриптовать работу с KSC.

По обоим пунктам есть документация в составе KSC, как это и указано в статьях, на которые я дал ссылки. Правда, документация эта вызывает ряд вопросов, которые можно задать в службу поддержки корпоративных продуктов CompanyAccount и получить ответ вида «Уточнили информацию. К сожалению, поддержка по скриптам для klakaut не оказывается.».

Минусы klakdb очевидны: чтобы напрямую обратиться к БД, нужно иметь к этой БД доступ, что приводит к необходимости лишних телодвижений по созданию правил доступа в межсетевых экранах, настройке прав доступа на серверах СУБД и прочему крайне неувлекательному времяпрепровождению. Ну и плюс мониторинг актуальности всех этих правил, естественно. Особенно интересно становится, когда имеется 20+ серверов — и все в разных филиалах, в каждом из которых свои администраторы.

Ну и вишенки на этом торте: доступ исключительно Read Only и, мягко говоря, неполная информация о среде. Плюсы не столь очевидны, но тоже есть: можно очень быстро выгрузить по одному серверу статистическую информацию по количеству хостов, используемым версиям антивирусов и антивирусных баз, а главное — можно весьма удобно (удобство зависит от знания SQL) работать с зарегистрированными на KSC событиями антивирусной инфраструктуры.

klakaut в этом плане значительно более интересен: подключившись к корневому серверу иерархии, можно средствами самого KSC пройтись по оной иерархии и получить доступ ко всем нужным данным. Например, построить дерево серверов KSC с пометкой, кто из них живой, а кто нет, позапускать задачи, поперемещать компьютеры и вообще дать волю фантазии.

Минусы тоже есть, естественно: долго и сложно. Если нужно собрать какую-то статистику — нужно будет сначала долго писать скрипт, а потом долго ловить баги ждать, когда он отработает.

Естественно, никто не запрещает (по крайней мере, мне про это неизвестно) использовать оба механизма вместе: например, пройтись по иерархии серверов с помощью klakaut, получить полный список серверов KSC с информацией об используемых БД, а потом уже передать эту информацию в более другие средства автоматизации, которые удалят устаревшие правила из сетевых экранов, создадут новые, дадут разрешения на доступ и принесут кофе в постель отредактируют список источников данных в вашей системе мониторинга, которая, в свою очередь, опросит список и, обнаружив какие-нибудь девиации, с помощью klakaut сделает что-нибудь хорошее. Ну, или просто зарегистрирует инцидент в трекере. Тогда что-нибудь хорошее сделают администраторы в ручном режиме.

Воодушевлённый всеми этими соображениями, я написал свой первый скрипт:

$Params = New-Object -ComObject 'klakaut.KlAkParams';
$Params.Add('Address', 'localhost:13000');
$Params.Add('UseSSL', $true);

$Proxy = New-Object -ComObject 'klakaut.KlAkProxy';
try {
    $Proxy.Connect($Params);
    $Proxy.Disconnect();
} catch {
    $_;
}

Remove-Variable -Name 'Params';
Remove-Variable -Name 'Proxy';

И запустил его на сервере:

Exception calling "Connect" with "1" argument(s): "Transport level error while connecting to http://localhost:13000: authentication failure"
At line:7 char:5
+     $Proxy.Connect($Params);
+     ~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ComMethodTargetInvocation

Начало хорошее.

Открыв консоль KSC, я убедился, что с правами у меня всё в порядке.

К сожалению, KSC не логирует неудачные попытки входа. Переписка с вендором показала, что логирование неудачных попыток входа можно включить (это была отдельная увлекательная история, которая, кстати, ещё не закончилась), однако данная конкретная попытка в логи всё равно попадать отказалась.

Казалось бы, можно сделать вот так:

$Params = New-Object -ComObject 'klakaut.KlAkParams';
$Params.Add('Address', 'localhost:13000');
$Params.Add('UseSSL', $true);

#------------ Зададим в явном виде данные для входа --------------------------------
$Params.Add('User', 'kavadmin');
$Params.Add('Password', 'P@ssw0rd');
$Params.Add('Domain', 'test');
#-----------------------------------------------------------------------------------

$Proxy = New-Object -ComObject 'klakaut.KlAkProxy';
try {
    $Proxy.Connect($Params);
    $Proxy.Disconnect();
}

Remove-Variable -Name 'Params';
Remove-Variable -Name 'Proxy';

В этом случае никаких ошибок не будет, но указывать логин с паролем открытым текстом в скрипте мне не показалось замечательной идеей. Новая переписка с техподдержкой ЛК подарила мне следующую рекомендацию:

Необходимо выставить в настройках COM, на вкладке Default Properties:
Default Authentication Level: Packet
Default Impersonation Level: Delegate

Эта инструкция заставила работать исходный скрипт, но показалась мне сомнительной в плане безопасности, поэтому я решил покопать чуть глубже. После некоторого времени поисков нашёлся добрый человек, который подсказал мне, как задать указанные уровни проверки подлинности и олицетворения для конкретного объекта, а не разрешать всем и всё сразу:

$Params = New-Object -ComObject 'klakaut.KlAkParams';
$Params.Add('Address', 'localhost:13000');
$Params.Add('UseSSL', $true);

$Proxy = New-Object -ComObject 'klakaut.KlAkProxy';

$code =  @"
using System;
using System.Runtime.InteropServices;

public class PowershellComSecurity
{
   [DllImport("Ole32.dll", CharSet = CharSet.Auto)]
   public static extern int CoSetProxyBlanket(IntPtr p0, uint p1, uint p2, uint p3, uint p4, uint p5, IntPtr p6, uint p7);

   public static int EnableImpersonation(object objDCOM) { return CoSetProxyBlanket(Marshal.GetIDispatchForObject(objDCOM), 10, 0, 0, 0, 3, IntPtr.Zero, 0); }
}
"@
Add-Type -TypeDefinition $code;
Remove-Variable -Name 'code';

[PowershellComSecurity]::EnableImpersonation($Proxy) | Out-Null;

try {
    $Proxy.Connect($Params);
    # <-- Вот сюда мы будем вставлять код
    $Proxy.Disconnect();
} catch {
    $_;
}

Remove-Variable -Name 'Params';
Remove-Variable -Name 'Proxy';

Вот так скрипт никаких ошибок выдавать не стал. Первый квест пройден.

Следующая задача: получить от KSC данные об используемой БД.

А вот тут всё сложно: документация о том, как это сделать, молчит. Исследование класса KlAkProxy ничего интересного не выявило, кроме параметра KLADMSRV_SERVER_HOSTNAME, который оказался идентификатором компьютера, на котором установлен KSC.

Перейдём тогда к компьютеру, для этого есть специальный класс KlAkHosts2. Для сокращения количества кода приведу только содержимое блока try:

try {
    $Proxy.Connect($Params);
    $KSCHost = New-Object -ComObject 'klakaut.KlAkHosts2';
    $KSCHost.AdmServer = $Proxy;
    $HostParams = New-Object -ComObject 'klakaut.KlAkCollection';
    $HostParams.SetSize(1);
    $HostParams.SetAt(0, 'KLHST_WKS_DN');
    ($KSCHost.GetHostInfo($Proxy.GetProp('KLADMSRV_SERVER_HOSTNAME'), $HostParams)).Item('KLHST_WKS_DN');
    Remove-Variable -Name 'HostParams';
    Remove-Variable -Name 'KSCHost';
    $Proxy.Disconnect();
}

Обратите внимание: переменная $Params, которую я использовал при подключении к KSC — экземпляр класса KlAkParams. А переменная $HostParams при, на мой взгляд, аналогичной функциональности, является экземпляром класса KlAkCollection. Почему используются разные классы — боюсь даже представить. Видимо, то, что SetAt принимает первым аргументом только целочисленные значения — очень принципиальный момент.

Данный код вернул значение «KSC», а значит, я на верном пути.

Метод GetHostInfo класса KlAkHosts2 достаточно хорошо задокументирован, но — не содержит нужной мне информации. Увы и ах. Зато есть метод GetHostSettings. Всё описание для которого сводится к следующему:

Returns host’s settings as setting storage.

Давайте, заглянем внутрь:

try {
    $Proxy.Connect($Params);
    $KSCHost = New-Object -ComObject 'klakaut.KlAkHosts2';
    $KSCHost.AdmServer = $Proxy;
    $KSCSettings = $KSCHost.GetHostSettings($Proxy.GetProp('KLADMSRV_SERVER_HOSTNAME'), 'SS_SETTINGS');
    $KSCSettings.Enum() | % {
        '------------------------';
        $tmp = $_;
        $tmp | % {"$_ = $($tmp.Item($_))";};
        Remove-Variable -Name 'tmp';
    };
    Remove-Variable -Name 'KSCSettings';
    Remove-Variable -Name 'KSCHost';
    $Proxy.Disconnect();
}

------------------------
PRODUCT = .core
SECTION = SubscriptionData
VERSION = .independent
------------------------
PRODUCT = 1093
SECTION = 85
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = 87
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KLEVP_NF_SECTION
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KLNAG_SECTION_DPNS
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KLSRV_CONSRVINIT
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KLSRV_CONSRVUPGRADE
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KLSRV_DEF_NAGENT_PACKAGE
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KLSRV_MASTER_SRV
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KLSRV_NETSIZE_SECTION
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KLSRV_PKG_ANDROID_CERT_SECTION
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KLSRV_PROXY_SECTION
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KLSRV_SRVLIC_SECTION
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KLSRV_USER_ACCOUNTS_SECTION
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KSNPROXY_KEY_STORAGE
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = KSNPROXY_SETTINGS
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = Packages
VERSION = 1.0.0.0
------------------------
PRODUCT = 1093
SECTION = Updater
VERSION = 1.0.0.0
------------------------
PRODUCT = 1103
SECTION = 85
VERSION = 1.0.0.0
------------------------
PRODUCT = 1103
SECTION = 86
VERSION = 1.0.0.0
------------------------
PRODUCT = 1103
SECTION = FileTransfer
VERSION = 1.0.0.0
------------------------
PRODUCT = 1103
SECTION = KLEVP_NF_SECTION
VERSION = 1.0.0.0
------------------------
PRODUCT = 1103
SECTION = KLNAG_KLNLA_DATA
VERSION = 1.0.0.0
------------------------
PRODUCT = 1103
SECTION = KLNAG_SECTION_NETSCAN
VERSION = 1.0.0.0
------------------------
PRODUCT = 1103
SECTION = KLNAG_SECTION_SERVERDATA
VERSION = 1.0.0.0
------------------------
PRODUCT = 1103
SECTION = Updater
VERSION = 1.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = .KLNAG_SECTION_REBOOT_REQUEST
VERSION = 8.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = 85
VERSION = 8.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = Backup section
VERSION = 8.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = Business logic section
VERSION = 8.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = HSM system section
VERSION = 8.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = Internal product info
VERSION = 8.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = KLEVP_NF_SECTION
VERSION = 8.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = Notification section
VERSION = 8.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = Predefined tasks section
VERSION = 8.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = Quarantine section
VERSION = 8.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = Reporting section
VERSION = 8.0.0.0
------------------------
PRODUCT = KAVFSEE
SECTION = Trusted processes section
VERSION = 8.0.0.0

В klakaut.chm есть раздел «List of KLHST_WKS_PRODUCT_NAME and KLHST_WKS_PRODUCT_VERSION values for products», где можно подсмотреть, что поле PRODUCT для KSC должно быть 1093, соответственно, всё остальное можно смело проигнорировать. Пока что, по крайней мере.

Пробежавшись глазами по названиям секций, я решил просмотреть 85 и 87, поскольку остальные на нужное мне были не очень похожи.

try {
    $Proxy.Connect($Params);
    $KSCHost = New-Object -ComObject 'klakaut.KlAkHosts2';
    $KSCHost.AdmServer = $Proxy;
    $KSCSettings = $KSCHost.GetHostSettings($Proxy.GetProp('KLADMSRV_SERVER_HOSTNAME'), 'SS_SETTINGS');
    $KSCSettings.Read('1093', '1.0.0.0', '85');
    '-----------------';
    $KSCSettings.Read('1093', '1.0.0.0', '87');
    Remove-Variable -Name 'KSCSettings';
    Remove-Variable -Name 'KSCHost';
    $Proxy.Disconnect();
}

EventFolder
EventStoragePath
KLAG_WAIT_SCHED_FOR_START_EVENT
TaskStoragePath
-----------------
KLSRV_AD_SCAN_ENABLED
KLSRV_CONNECTION_DATA
KLSRV_DATABASENAME
KLSRV_NET_SCAN_ENABLED
KLSRV_SERVERINSTANCENAME
KLSRV_SP_DPNS_ENABLE
KLSRV_SP_FASTUPDATENET_PERIOD
KLSRV_SP_FULLUPDATENET_PERIOD
KLSRV_SP_INSTANCE_ID
KLSRV_SP_MAX_EVENTS_IN_DB
KLSRV_SP_OPEN_AKLWNGT_PORT
KLSRV_SP_SCAN_AD
KLSRV_SP_SERVERID
KLSRV_SP_SERVERID_DPE
KLSRV_SP_SERVER_AKLWNGT_PORTS_ARRAY
KLSRV_SP_SERVER_PORTS_ARRAY
KLSRV_SP_SERVER_SSL_PORTS_ARRAY
KLSRV_SP_SERVER_SSL_PORTS_ARRAY_GUI
KLSRV_SP_SYNC_LIFETIME
KLSRV_SP_SYNC_LOCKTIME
KLSRV_SP_SYNC_SEC_PACKET_SIZE
KLSRV_SSL_CERT_RSA_BIT_NUMBER

Секция 85, судя по всему, отвечает за события и ныне нам неинтересна. А вот в 87 есть что-то, на что стоит обратить внимание:

try {
    $Proxy.Connect($Params);
    $KSCHost = New-Object -ComObject 'klakaut.KlAkHosts2';
    $KSCHost.AdmServer = $Proxy;
    $KSCSettings = $KSCHost.GetHostSettings($Proxy.GetProp('KLADMSRV_SERVER_HOSTNAME'), 'SS_SETTINGS');
    $87 = $KSCSettings.Read('1093', '1.0.0.0', '87');
    "KLSRV_SERVERINSTANCENAME = $($87.Item('KLSRV_SERVERINSTANCENAME'))";
    "KLSRV_DATABASENAME = $($87.Item('KLSRV_DATABASENAME'))";
    "KLSRV_CONNECTION_DATA =`r`n$($87.Item('KLSRV_CONNECTION_DATA') | % {"`t$_ = $($87.Item('KLSRV_CONNECTION_DATA').Item($_))`r`n";})";
    Remove-Variable -Name '87';
    Remove-Variable -Name 'KSCSettings';
    Remove-Variable -Name 'KSCHost';
    $Proxy.Disconnect();
}

KLSRV_SERVERINSTANCENAME = .
KLSRV_DATABASENAME = KAV
KLSRV_CONNECTION_DATA =
	KLDBCON_DB = KAV
 	KLDBCON_DBTYPE = MSSQLSRV
 	KLDBCON_HOST = .

Тут я воспользовался одним из предыдущих кейсов, где упоминалось, что нужные данные следует брать именно из KLSRV_CONNECTION_DATA (тогда я ещё не знал, что это вообще такое, просто отложилось).

Ну, вот, в общем-то, и всё. Данные об используемой БД получены. Квест пройден.

Наверное, ещё неплохо бы набросать скрипт для прохождения по иерархии серверов. Здесь ничего загадочного не оказалось, всё было вполне по документации. Я написал скрипт, который выбирает UID родителя, UID самого сервера, экземпляр СУБД и имя БД и выводит их в stdout через разделитель.

$SrvAddr = 'localhost:13291'

function EnumSrv(
    $Pxy,
    [bool]$IsAlive = $true,
    [string]$ParentPxyId = 'Root'
)
{
    [string]$result = "$ParentPxyId";
    if ($IsAlive) {
        $result += "|$($Pxy.GetProp('KLADMSRV_SERVER_HOSTNAME'))";
        
        $Hosts = New-Object -ComObject 'klakaut.KlAkHosts2';
        $Hosts.AdmServer = $Pxy;
        
        $Settings = $Hosts.GetHostSettings($Pxy.GetProp('KLADMSRV_SERVER_HOSTNAME'), 'SS_SETTINGS').Read('1093', '1.0.0.0', '87').Item('KLSRV_CONNECTION_DATA');
        Remove-Variable -Name 'Hosts';
    
        #'-------->   DB  Info <--------';
        $result += "|$($Settings.Item('KLDBCON_HOST'))";
        $result += "|$($Settings.Item('KLDBCON_DB'))";
        #'-----------------------------';
        
        Remove-Variable -Name 'Settings';
        
        $SlaveSrvEnum = New-Object -ComObject 'klakaut.KlAkSlaveServers';
        $SlaveSrvEnum.AdmServer = $Pxy;
        $SlaveServers = $SlaveSrvEnum.GetServers(-1);
        
        $SlaveServers | % {
            $Child = $_;
            $TmpSrvId = $Child.Item('KLSRVH_SRV_ID');
            $HostActive = $true;
            try
            {
                $TmpSrv = $SlaveSrvEnum.Connect($TmpSrvId, -1);
            }
            catch
            {
                $HostActive = $false;
            };
            if ($HostActive) {$HostActive = ($TmpSrv.GetProp('IsAlive') -eq 1);};
            $result += "`r`n$(EnumSrv -Pxy $TmpSrv -IsAlive $HostActive -ParentPxyId $Pxy.GetProp('KLADMSRV_SERVER_HOSTNAME'))";
        };
        Remove-Variable -Name 'SlaveServers';
        Remove-Variable -Name 'SlaveSrvEnum';
    };
    return ("$result`r`n");
}

Clear-Host

$Params = New-Object -ComObject 'klakaut.KlAkParams'
$Params.Add('Address', $SrvAddr)
$Params.Add('UseSSL', $true)

$code =  @"
using System;
using System.Runtime.InteropServices;

public class PowershellComSecurity
{
   [DllImport("Ole32.dll", CharSet = CharSet.Auto)]
   public static extern int CoSetProxyBlanket(IntPtr p0, uint p1, uint p2, uint p3, uint p4, uint p5, IntPtr p6, uint p7);

   public static int EnableImpersonation(object objDCOM) { return CoSetProxyBlanket(Marshal.GetIDispatchForObject(objDCOM), 10, 0, 0, 0, 3, IntPtr.Zero, 0); }
}
"@
Add-Type -TypeDefinition $code

$Srv = New-Object -ComObject 'klakaut.KlAkProxy'
[PowershellComSecurity]::EnableImpersonation($Srv) | Out-Null
$Srv.Connect($Params)

"ParentPxyId|KLADMSRV_SERVER_HOSTNAME|KLDBCON_HOST|KLDBCON_DB`r`n" + (EnumSrv -Pxy $Srv);
Remove-Variable -Name 'Srv';
Remove-Variable -Name 'Params';

Стенд маленький, поэтому результат оказался не очень впечатляющим:

ParentPxyId|KLADMSRV_SERVER_HOSTNAME|KLDBCON_HOST|KLDBCON_DB
Root|9d476a75-1e36-4c0e-8145-56e5b888df67|.|KAV
9d476a75-1e36-4c0e-8145-56e5b888df67|ef4fc3be-3abd-4322-ae35-2c50afdce780|.KAV_CS_ADMIN_KIT|KAV

Естественно, чтобы превратить точку в актуальное имя сервера, придётся поколдовать с KlAkHosts2.GetHostInfo(), но это уже не столь страшно, просто ещё сколько-то кода.

Техподдержка ЛК, естественно, пугала меня тем, что структура SS_SETTINGS в следующих релизах KSC может поменяться, поэтому так лучше не делать. К сожалению, даже мой внутренний перфекционист считает, что скрипт нельзя просто написать и забыть: при смене версии используемого ПО его по-любому придётся тестировать и отлаживать. Так что пока пользуемся тем, что есть, а проблемы будем решать по мере поступления, благо, техника уже отработана.

Автор: wlnx

Источник