Jump to content

Recommended Posts

Posted

Здравствуйте! Создал профиль политики, которая перевела агенты KSC в автономный режим. Можно ли вывести агенты из автономного режима с помощью какого-нибудь скрипта? Обновление агента оставило прежнюю политику агента. В свойствах задачи деинсталляции агента поле Учетной записи для пароля деинсталляции серое, нет возможности вбить имя KLAdmin, в результате пароль не проходит, задача деинсталляции не исполняется.

Posted

что именно было в профиле подключения (для агента) правилом перехода ?

вы сменили агенту адрес сервера подключения к KSC ?

 

ну несколько вариантом как исправить ситуацию

1. отключите автономную политику на сервере KSC, и отключите профиль

2. На клиенте - если агент переключился на управление к другому серверу KSC, попробуйте сменить ему подключения утилитой klmover

C:\Program Files (x86)\Kaspersky Lab\NetworkAgent\klmover.exe -address <IP вашего KSC>

2.1 или удалите агента, переустановите его из автономного пакета например ... проведите синхронизацию ... чтобы вылетал новые политики для себя и  KES

 

16 минут назад, mmma сказал:

Учетной записи для пароля деинсталляции серое, нет возможности вбить имя KLAdmin

судя по этому вы пытаетесь удалить KES ...

Posted

Правилом перехода было отсутствие DHCP сервера, агент не переключался на другой сервер. Если настроить виндовз на клиенте на получение ip адреса по DHCP, то агент подключается к серверу. Но такая возможность есть не для всех виндовз станций.

Пытался удалить агента. Для удаления агента похоже нужен только пароль, без имени. Пароль почему-то не проходит, поэтому нет возможности переставить агента. Буду благодарен за совет как удалить агента без пароля.

 

Posted

@mmma, добрый день. В политике Агента администрирования у вас задан свой пароль (вспоминайте его...), там нет имени пользователя. Это не пароль от KES.

Как передать в CLI пароль для удаления:

 

Posted
15 минут назад, mmma сказал:

отсутствие DHCP сервера

не самый удачный вариант ...

во первых используйте сразу несколько значений, в рекомендациях -  использовать возможность подключения по SSL к какому нибудь серверу (например к самому же KSC), и резолв DNS имена внутреннего сервера (например DC)...

самый простой способ это все же прописать условия при которых агент подключится в KSC на котором вы ДОЛЖНЫ отключите все свои автономные политики и профили, и правила перехода. В политике Агента можно будет сменить пароль (если это еще будет актуально).

ранее была утилита на удаление следов установки агента - но сейчас и она проси пароль. - https://support.kaspersky.ru/ksc13/tools/13088

поэтому если ситуация совсем плохая ... пищите а CA

 

Расскажите что вы хотели сделать и как это реализовывали (со скриншотами), и для чего вам это было нужно

посмотрим как это можно сделать.

Posted
2 часа назад, Demiad сказал:

(вспоминайте его...), там нет имени пользователя. Это не пароль от KES.

вспомнить не удалось, больше способов сменить нет?

 

1 час назад, ElvinE5 сказал:

пищите а CA

не понятно.

 

1 час назад, ElvinE5 сказал:

Расскажите что вы хотели сделать и как это реализовывали (со скриншотами), и для чего вам это было нужно

хотели создать профиль KES, включающий WiFi при отключении станции от рабочей сети. 

Как оказалось, изначально нами неправильно предполагалось, что:

1. Автономный режим - это режим станции без сети, а не агента без подключения к KSC, и поэтому он (автономный режим) выключится при подключении к WiFi, и поэтому необходимо выполнение второго условия (OutOfMF) - проверка адреса DHCP сервера, которая оставляет этот профиль агента активным при появлении DHCP отличных от рабочих (например WiFi).

2. Профиль подключения "Офлайн-режим", который никак не настраивается и не просматривается и кажется просто названием для создаваемого профиля, на самом деле уже включает автономный режим агента!!! при выполнении условия переключения. 

Т.о. при отключении станции от рабочей сети пропадают указанные DHCP серверы, сетевое местоположение становится = OutOfMF (выполнено 2е условие). Станция теряет подключение к KSC (выполнено 1е условие), активируется профиль политики KES (включается доступ к WiFI). 

При включении станции в рабочую сеть все возвращается как было.

Однако политика агента применилась также на станции без DHCP (ip постоянные, без DHCP). И теперь у них агент в автономном режиме, и непонятно как его выключить не переустанавливая агента. При этом еще пароль для удаления агента не совпадает с паролем для kes и похоже утерян.

 

 

ris1.jpg

ris2.jpg

Posted (edited)

Так, стало понятнее ... интересный подход ... но все же по моему не до конца разобрались с вопросом.

по порядку

В 01.12.2023 в 19:08, mmma сказал:

вспомнить не удалось, больше способов сменить нет?

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

В 01.12.2023 в 19:08, mmma сказал:

не понятно.

Прошу прощения вот сюда - https://companyaccount.kaspersky.com/account/login

 

теперь по восстановлению ... если я правильно понимаю вы все же выбрали предустановленный профиль Out-of-office, а не настраивали его в ручную значить проблем в с подключением агента быть не должно. Но из за того что для части машин ваше правила нахождения в сетевом местоположении срабатывает  постоянно  к ним применяется постоянно профиль политики OutOfMF и перевод устройство режим Out-of-office

Агент проверяет сове местоположение каждые 60 секунд, и при каждом изменении подключения (банально отключить и подключить кабель)

что за режим

Спойлер

.thumb.png.f17a7438906bb381a277f1a64053a713.png

Спойлер

.thumb.png.5580dba9467354f7f793518d12797144.png

То есть находясь в этом режиме система будет применять специальную политику (созданную заранее) - "Политика для автономных пользователей" если такой политики НЕТ то свою основную политику.

вы же сделали активацию "Профиля политики" на основании сетевого местоположения, где внесли нужные вам изменения.

 

1. Проверьте имеет ли агент на проблемной машине возможность соединится с сервером администрирования, воспользуйтесь утилитой klnagchek

PS C:\Program Files (x86)\Kaspersky Lab\NetworkAgent>klnagchek.exe

или графическая утилита по этому же пути klcsngtgui.exe

Спойлер

.thumb.png.70eb7cf2629fe4236bfc4a5649a6eebc.png

Спойлер

.thumb.png.ffbc1584bfb83e0a4f9896869577361f.png

проверьте что проблем нет

 

2. из политики KES удалите (или отключите) ваш профиль политики активируемый при условии что устройство в заданном вами сетевом местоположении OutOfMF.

Спойлер

.thumb.png.224864a29a5cbf8d32ec47e02f7f8b64.png

 

3. в Политике для агента удалите или отключите описание сетевого местоположения

Спойлер

.thumb.png.1871a0c366f3e1bb1ae00baa850fddf5.png

после очередного периода синхронизации система должна перейти на использование основной политике KES.

 

по настройке ... как бы сделал я

не совсем понятно как у вас устройства отключаются от сети и подключаются назад ... предположу базовый вариант

Условия

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

1. Создание Автономной политики

Спойлер

.thumb.png.879d9909575c37b01a2d2ed5c760ac75.png

Не путаем с профилем для сетевого расположения (был слайд в начале)

Создается и настраивается так же как и обычная политика за исключением того что выбираем что она бывает "Политикой для автономных пользователей" (настройки родительской Активной политика не наследуются)

Спойлер

.thumb.png.b8f33d2765b10820b47f391f1a3e3e38.png

устройство должно получить эту политику до того как покинет приделы сети.

По сути к одному устройству будут применяться 2е политики, но пока устройство не в режиме Out-of-office работать будет Активная

 

2. Настройка перехода в режим Out-of-office

2.1 включить переход при отсутствии сервера

в настройках политики агента администрирования включаем переход ...

Спойлер

.thumb.png.0eabb5f6786b0e4bc3b5d7099d5f4fc5.png

это позволит Агенту переводить устройство в режим Out-of-office при недоступности сервера KSC. И произойдет это в случаи когда агент не сможет в трех подряд периодах синхронизации получить доступ к серверу (это важно). После чего клиент начинает использовать Автономную политику  в качестве основной ... ДО МОМЕНТА возвращения в сеть и подключения в серверу KSC.

В принципе на базовом уровне этого должно быть достаточно, однако не всегда удобно, так как переход выполниться после 3-х неудачных попыток подключения агента с серверу KSC (а это с среднем порядка 45+ минут)

для более точного перехода нам поможет правила сетевого расположения.

 

2.2 правила сетевого расположения

Базовые понятия

Спойлер

.thumb.png.d42aa6417833a0908fe1d6a1bbc00993.png

из этого слайда нам важно понимать что

- Правила дают агенту понять где он находится (по нашему определению)

- Профили что с этим делать дальше

вы правильно заметили что у системы есть два предустановленных профиля ... вот детали.

Спойлер

.thumb.png.a1bf801d83b802fb2c06f20c82be6517.png

Для нашей задачи превосходно подойдет готовый профиль "Offline mod" поэтому создавать собственный профиль нет нужды.

теперь нам надо описать правилами при каких обстоятельствах агент должен переключить работу клиента в режим Out-of-offie

вот рекомендации по выбору правил

Спойлер

.thumb.png.1cba9956d2973469cd7200d9db837e01.png

выбираем последние два, не забываем их "инвертировать"

я выбрал разрешимость имени моего контролера домена и SSL подключение к серверу KSC

Спойлер

91519683_.png.b35ad3f0efb886a7ca4d99d40c5a9a2b.png

Спойлер

.thumb.png.6fd6d8470e962983c9f5f4d347d00904.png

сертификат сервера можно найти по этому пути - C:\ProgramData\KasperskyLab\adminkit\1093\cert

 

агент переключится в режим Out-of-office в случаи когда не сможет разрешить имя сервера и подключится к KSC по SSL

 

 

Использовать профиль политики вместо политики для Автономных пользователей, тоже вариант, но я бы настроил активацию так ...

Спойлер

.thumb.png.5f009f4d46d673e23fa8351e4446701a.png

в вашем случаи устройства будут применять профиль политики и когда устройство само перешло в режим Out-fo-offise (3-и неудачные попытки подключения) или по правилам сетевого месторасположения (а там у нас как раз активируется этот режим) ... и это может нам быть не всегда нужно ...

 

неважно какой подход вы выберите важно понимать

Правило сетевого местоположения должны как можно точнее описывать момент когда агент должен перейти на работу от заданного вами профиля подключения (не путать с профилем политики)

 

Надеюсь не запутал вас еще сильнее

 

Edited by ElvinE5
Posted
3 часа назад, ElvinE5 сказал:

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

агенты без связи с сервером, в этом вся проблема. Новые политики агента с новым паролем именно на них не накатываются. Если бы накатились, то и удалять агента бы не пришлось. Смысл удаления агентов в переводе их в онлайн режим.

 

3 часа назад, ElvinE5 сказал:

1. Проверьте имеет ли агент на проблемной машине возможность соединится с сервером администрирования, воспользуйтесь утилитой klnagchek

Запуск утилиты 'klnagchk'...
Проверка параметров командной строки...OK
Инициализация базовых библиотек...OK
Текущее устройство '**********************'
Версия Агента администрирования '13.0.0.11247 (openssl)'


Чтение параметров...OK
Проверка параметров...OK
Параметры Агента администрирования:
  Адрес Сервера администрирования: '<Без подключения>'
  

Местоположения

  Название местоположения: OutOfMF
  Состояние сетевого местоположения: Включено
  Использовать профиль: <Офлайн-режим>
  Условие: Адрес DHCP-сервера, ни один из 10.****0, 10.*****2, 10.*****1, 10.*****9

  Период синхронизации (мин): 15
  Тайм-аут соединения (сек): 30
  Тайм-аут отправки/приема (сек): 180
  Идентификатор устройства:

Попытка соединения с Агентом администрирования...OK
Агент администрирования запущен.
Получение статистики Агента администрирования...OK
  Статистика Агента администрирования:
  Всего запросов на синхронизацию: 0
  Успешных запросов на синхронизацию: 0
  Всего синхронизаций: 0
  Успешных синхронизаций: 0
  Дата/время последнего запроса на синхронизацию: 28.11.2023 11:47:48 GMT (28.11.2023 14:47:48)


 

3 часа назад, ElvinE5 сказал:

2. из политики KES удалите (или отключите) ваш профиль политики активируемый при условии что

отключил 5 дней назад

 

3 часа назад, ElvinE5 сказал:

3. в Политике для агента удалите или отключите описание сетевого местоположения

удалил 5 дней назад

3 часа назад, ElvinE5 сказал:

после очередного периода синхронизации система должна перейти на использование основной политике KES.

не синхронизируется 5 дней, не переходит.

 

3 часа назад, ElvinE5 сказал:

Надеюсь не запутал вас еще сильнее

не запутали. Очень подробно все описали, обязательно пригодится в дальнейшем!

  • Solution
Posted (edited)

понятно ...в вашем случаи на агента продолжает действовать ваше правило с DHCP и пока оно не будет нарушено, агент похоже не вернется в "лоно церкви"

1. вам можно подключить проблемное устройство к сети там где он сможет получить DHCP

2. есть один вариант ... со сменой сервера администрирования

я настроил профиль перехода и он прекрасно отрабатывает ...

Спойлер

.thumb.png.62ec1193f30e96293ce220def34e89c3.png

в этом состоянии я использовал смену сервера администрирования ...

C:\Program Files (x86)\Kaspersky Lab\NetworkAgent>klmover -address 10.111.10.12

заставив его принудительно сменить сервер на мой же ...

и вот что получилось ...

Спойлер

.thumb.png.567b71c928fba7973c4eca3f7e30291f.png

как видите сервер есть в настройках и самое главное ... "СНЕСЛО" все настройки профилей сетевого расположения.

после чего клиент вновь подключился ... и снова все настройки обновил (также скачав описание профилей)

если проблемное устройство пигнует сервер KSC ... попробуйте такой вариант

 

на ошибку подключения не обращать внимание - потому как у меня кабель не подключен что бы имитировать нахождение вне офиса. Полностью имитировать вашу ситуацию не стал 🙂 при этом команда смены сервера отработала нормально.

Edited by ElvinE5
  • Thanks 1
Posted
54 минуты назад, ElvinE5 сказал:

после чего клиент вновь подключился ... и снова все настройки обновил (также скачав описание профилей)

Сработало!! Действительно, агент переподключился к серверу и обновил политики. Странно, что политика агента не обновлялась при переходе на новую версию агента. Вижу что задача обновления агентов на новую версию, которой я пытался исправить ситуацию, действительно проходила успешно, у агентов новая версия. Ларчик открывался простым klmover`ом. Проблема решена, Спасибо!!!

Posted
16 часов назад, mmma сказал:

Странно, что политика агента не обновлялась при переходе на новую версию агента.

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

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now


×
×
  • Create New...