Jump to content
ff4pierre

administration postes nomades : impossible

Recommended Posts

Bonjour,

 

J'ai un soucis avec mes postes nomades qui sont considéré comme déconnecté depuis longtemps.

 

Voici la configuration actuelle de mes ports :

 

- Serveur d'administration : Port ouvert = UDP 13000 ; TCP 13000 ; TCP 14000

- Poste nomade : Port ouvert : UDP 15000

 

J'ai lancé un klnagchk.exe sur les postes nomades dont voici le résultat :

 

- Utiliser une connexion SSL : 1

- Compresser le traffic : 1

- N° de port SSL du serveur d'administration : 13000

- N° de port du serveur d'administration : 14000

- Utiliser un proxy : 0

- Certificat du serveur d'administration : disponible

- Découvrir port UDP : 1

- N° de port UDP : 15000

 

- Période de synchro : 15 min

- Temporisation de connexion : 30 sec

- Temporisation d'envoi / reception : 100 sec

 

Tentative de connexion au serveur d'administration (FQDN:13000) : refus de connexion

Tentative de connexion à l'agent d'administration : OK

Agent en cours d’exécution : OK

Réception des stats de l'agent d’administration OK

Nombre de requêtes de synchro : 0

Nombre de requêtes de synchro réussies : 0

Nombre de synchro : 0

Nombre de synchro réussies : 0

 

Voila pour les logs.

Autres info j'ai activer "maintenir la connexion au serveur d'administration" sur mes deux postes nomades.

Share this post


Link to post

Bonjour,

 

Votre Security Center est dans votre réseau local ? Si tel est le cas, vérifier les règles sur votre firewall pour que les ports TCP 13000 et TCP 14000 soient correctement redirigés vers IP local de votre Security Center ?

Depuis l'extérieur parvenez-vous à faire un Telnet en utilisant le nom FQDN du Security Center sur le port 13000 ?

Au vu du message figurant dans le résultat du klnagchk "Tentative de connexion au serveur d'administration (FQDN:13000) : refus de connexion" cela ne semble pas être le cas.

 

Pour quelle raison avez-vous coché "maintenir la connexion" sur vos postes nomades ?

 

Bonne journée,

Magali

 

PS: le post ayant été posté en double nous avons désactivé le doublon :)

 

Share this post


Link to post
Bonjour,

 

Votre Security Center est dans votre réseau local ? Si tel est le cas, vérifier les règles sur votre firewall pour que les ports TCP 13000 et TCP 14000 soient correctement redirigés vers IP local de votre Security Center ?

Depuis l'extérieur parvenez-vous à faire un Telnet en utilisant le nom FQDN du Security Center sur le port 13000 ?

Au vu du message figurant dans le résultat du klnagchk "Tentative de connexion au serveur d'administration (FQDN:13000) : refus de connexion" cela ne semble pas être le cas.

 

Pour quelle raison avez-vous coché "maintenir la connexion" sur vos postes nomades ?

 

Bonne journée,

Magali

 

Bonjour,

 

Oui il se trouve bien dans mon réseau local.

Sur mon pare-feu son redirigé les ports TCP 13000 et 14000 ainsi que UDP 15000 vers mon serveur.

 

Depuis l’extérieur lorsque je fait un telnet j'ai une simple fenêtre noir sans prompt ni message d'erreur.

 

Si j'ai cocher maintenir la connexion c'est parce que j'ai suivi la procédure kaspersky suivante :

 

Le Serveur d'administration à distance doit posséder l'adresse IP externe, et sur cette

adresse les ports entrants 13000 et 14000 doivent être ouverts.

- Des Agents d'administration doivent être installés sur les ordinateurs clients = OK

 

- Lors de l'installation de l'Agent d'administration sur les ordinateurs clients, l'adresse IP

externe du Serveur d'administration à distance doit être indiquée. Si pour l'installation, le

paquet d'installation est utilisé, alors l'adresse IP doit être indiquée manuellement dans les

propriétés du paquet d'installation dans la section Paramètres = OK (sauf que j'utilise le nom FQDN)

 

- Pour administrer les applications et les tâches de l'ordinateur client à l'aide du Serveur

d'administration à distance, il faut cocher la case Maintenir la connexion au Serveur

d'administration dans la fenêtre des propriétés de cet ordinateur dans la section Général = OK

 

 

Pouvez-vous me confirmer qu'il est bien possible avec des postes nomades de les administrer comme si ils se trouvaient sur le réseau local ? (synchronisation forcé, lancement de tache,...)

 

Merci pour vos réponses.

EDIT : J'ai ma réponse pour telnet. Le service est inexistant pour windows server 2016

Edited by ff4pierre

Share this post


Link to post

Bonjour ff4pierre et merci pour les précisions.

 

Pourriez-vous s'il vous plait nous ajouter les versions des produits KSC (niveau de correctif installés) et KES utilisés s'il vous plait ?

Pour cela, consulter le Rapport sur les versions des logiciels de Kaspersky Lab.

Créez un rapport avec le champ "Mises à jour installées" si colonne pas présente:

- Ouvrez les propriétés du rapport.

- Accédez à la section Champs détails.

- Cliquez sur le bouton Ajouter.

- Dans la liste déroulante du champ Nom du champ sélectionnez Mises à jour installées.

- Cliquez sur OK.

 

Pour revenir au souci, sauf erreur, il est possible que cela soit lié à un souci DNS ou fichier host sur le poste.

Sur un des postes nomades, exécuter la commande klmover -address IP_server_KSC afin de reparamétrer l'agent d'administration avec l'IP.

plus d'info sur cette commande sur http://support.kaspersky.com/fr/9290

 

Concernant l'option "Maintenir la connexion..", cette dernière permet en effet d'avoir un poste distant qui sera administré comme sur le LAN, cependant il est recommandé de l'utiliser uniquement sur des postes ou servers importants car cette fonctionnalité consomme pas mal de ressources sur le serveur d'administration.

Aussi, actuellement le maintien de la connexion ne peut être réalisé. Elle se fera uniquement lorsque la synchronisation avec votre serveur redeviendra opérationnelle.

 

Dans l'attente de votre retour.

Share this post


Link to post
Bonjour ff4pierre et merci pour les précisions.

 

Pourriez-vous s'il vous plait nous ajouter les versions des produits KSC (niveau de correctif installés) et KES utilisés s'il vous plait ?

Pour cela, consulter le Rapport sur les versions des logiciels de Kaspersky Lab.

Créez un rapport avec le champ "Mises à jour installées" si colonne pas présente:

- Ouvrez les propriétés du rapport.

- Accédez à la section Champs détails.

- Cliquez sur le bouton Ajouter.

- Dans la liste déroulante du champ Nom du champ sélectionnez Mises à jour installées.

- Cliquez sur OK.

 

Pour revenir au souci, sauf erreur, il est possible que cela soit lié à un souci DNS ou fichier host sur le poste.

Sur un des postes nomades, exécuter la commande klmover -address IP_server_KSC afin de reparamétrer l'agent d'administration avec l'IP.

plus d'info sur cette commande sur http://support.kaspersky.com/fr/9290

 

Concernant l'option "Maintenir la connexion..", cette dernière permet en effet d'avoir un poste distant qui sera administré comme sur le LAN, cependant il est recommandé de l'utiliser uniquement sur des postes ou servers importants car cette fonctionnalité consomme pas mal de ressources sur le serveur d'administration.

Aussi, actuellement le maintien de la connexion ne peut être réalisé. Elle se fera uniquement lorsque la synchronisation avec votre serveur redeviendra opérationnelle.

 

Dans l'attente de votre retour.

 

Bonjour,

 

Désolé de ne pas avoir répondu plus tôt, je n’avais pas vu la réponse.

 

Serveur d'administration :

Version KSC : 10.3.407

Version KES10 : 10.0.0.486 : KB12644 + KB13017

 

Postes nomades :

Version KES10 : 10.2.5.3201

 

Le fichier host et DNS sont OK.

J'ai passé la commandes klmover en question avec au lieu de l'IP le FQDN.

 

Cordialement.

Share this post


Link to post

les redirections de ports entrants sont correctes ?

Share this post


Link to post

Bonsoir ff4pierre,

 

du nouveau suite à la reconfiguration des paramètres du serveur KSC à l'aide de la commande klmover ?

 

Quel est le résultat d'un telnet depuis le poste nomade vers le port cible du KSC ?

 

Bonne soirée.

Share this post


Link to post

×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.