Jump to content

Scal

KL France
  • Content Count

    472
  • Joined

  • Last visited

3 Followers

About Scal

  • Rank
    Cadet

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Bonsoir Epate, peux-tu nous lister précisément les stratégies que tu tentes de comparer ? ( 2 x KES 10 SP2 , 1x KES 10 SP2 et 1x KES 10 SP1 MR2, ....) Les plugins d'administration correspondant à chacune des versions de ces stratégies sont-ils correctement installés dans la console d'administration ? ==> clic-droit sur "Serveur d'administration" > Propriétés > Avancé > Informations sur les plugins d'administration des applications installées Merci.
  2. Bonsoir tophe59380, est-ce que tu t'es assuré que le résultat de la commande klnagchk de l'agent était bien cohérent après modification du serveur d'administration ? Est-ce qu'une recherche de ta station depuis la console du serveur virtuel donne quelque chose ? ==> clic-droit sur le noeud "serveur d'administration - nom du virtuel" > recherche > réseau Bonne soirée.
  3. Bonjour LIONEL01, j'ai fait un petit raccourci dans mes explications précédentes. En fait, plus précisément l'outil logonsession te permettra de lister toutes les sessions actives de Windows d’un ordinateur local ou d’un contrôleur de domaine et ainsi tu pourras identifier l'utilisateur qui a tenté d'accéder au partage protégé dont il est question. Je te donne un autre exemple de recherche ici en combinant les deux outils Systernals Logonsession et PsLoggedon utilisés depuis un contrôleur de domaine : En espérant avoir pu t'aider. :)
  4. Envoi-moi STP en MP le résultat de la commande : logonsessions.exe -p
  5. Bonjour Lionel01, je te rassure ce comportement est tout à fait normal et fait parti d'une limitation liée au design actuel du produit. La valeur "0-45a98f36 " correspondant au LUID (Locally Unique Identifier) de l'ordinateur considéré comme douteux. En fait, le composant "Blocage de l'accès aux fichiers réseaux" sera en mesure d'afficher le nom DNS/IP de l'hôte distant uniquement si les informations sur l'ouverture de session ont déjà été consignées dans les journaux d'évènements et déjà été traitées par la solution Kaspersky Security 10 for Windows Servers lors du blocage de l'ordinateur. Si les détails sur l'ouverture de session n'ont pas encore été traités par l'antivirus lors du blocage , alors seul le LUID du hôte sera affiché dans la liste des ordinateurs douteux. Afin d'identifier la correspondance entre un LUID et un hôte cible, je te conseille d'utiliser l'outil " LogonSessions" de Microsoft disponible ci-dessous : https://technet.microsoft.com/en-us/sysinternals/bb896769 En espérant avoir pu t'apporter l'aide nécessaire.
  6. Parfait, il y avait manifestement un souci avec l'application des règles prédéfinies manuellement. Je te conseille vraiment de conserver KSN actif à l'avenir pour la classification auto de tes exécutables, ça te facilitera grandement l'administration. Bonne journée.
  7. Du coup, ton souci de conflit avec l'application StarLeaf s'est-il réglé de lui même après activation de la technologie KSN ?
  8. Bonjour Jinx02, en ce qui concerne la technologie KSN, je t'offre ici un peu de lecture, ça devrait te rassurer sur le sujet : https://www.kaspersky.fr/about/data-protection https://support.kaspersky.com/fr/9464 https://support.kaspersky.com/fr/9365#block0 https://support.kaspersky.com/fr/14325 Je te recommande vivement d'utiliser cette technologie au quotidien, avec le recul je peux te dire qu'elle a sauvé la mise à beaucoup clients lors de phases d'attaques virales. Pour le tweak "support technique", je me doutais un peu mais voilà ce que j'ai de mon côté : Ta capture illustre manifestement qu'aucune mention n'a été spécifié dans la section "Informations sur le Support Technique" de ta policy. As-tu ajouté un commentaire dans la section "Assistance aux utilisateurs > Informations sur le Support Technique" de ta policy ? voir ci-dessous : En espérant t'avoir apporté toute l'aide nécessaire ! Bonne journée.
  9. Jinx02, cela est tout à fait normal, le module de contrôle de l'activité des applications s'appuie sur la base de réputation KSN pour une classification automatique des applications dans ses groupes de filtrages (de confiance, restrictions faibles ...). Si tu n'actives pas la technologie KSN, il faudra définir les règles pour tes applications à la main, ce qui complique grandement la tâche sachant qu'il peut exister plusieurs versions de ton application métier et par conséquent plusieurs MD5 potentiels en fonction de la version de ton application. Tu peux te référer à ce lien afin de vérifier la réputation d'un exécutable par exemple : https://whitelisting.kaspersky.com/advisor Je ne vois même pas comment faire pour le faire manuellement à vrai dire... Afin de sortir ton poste de la policy, il faut tout d'abord positionner un login / mot de passe de protection sur ta policy. (Paramètres généraux > Interface > Mot de passe de protection ) Puis localement : Et le tweak sur la section "Informations support technique", on le retrouve où côté KES11 car je ne vois rien (j'ai fait ton test pour être sûr...) 
  10. Si tu sors ton poste de la stratégie (Icone K de la barre des tâches > clic-droit > désactiver la stratégie) et que tu regardes localement la classification de ton exécutable, est-il toujours dans le groupe de confiance du composant prévention des intrusions ? Si tel n'est pas le cas, ajoute-le manuellement et effectue de nouveau tes tests. Tiens nous informés du résultat.
  11. Bonjour logaviv, peux-tu nous communiquer l'URL dont il est question STP. S'agit-il du module "Antivirus Internet" ou "Contrôle Internet" ? As-tu tester d'autres navigateurs que Opéra ? verdict ? Merci par avance pour tes réponses et bonne journée à toi !
  12. Salut Jinx02, tu as souligné une chose importante plus haut : Il semblerait que côté KSC, dans ma stratégie, la classification des exécutables StarLeaf soit correcte par rapport à mes attentes : en zone de confiance. Par contre, côté client, KES11 et ses rapports indiquent qu'ils sont en zone avec restrictions faibles mais dans cette zone, par défaut, l'accès à la webcam et au micro est interdit... Incohérence entre serveur et client. Il semble qu'il y ait une incohérence entre ce qui est configuré dans ta policy et ce qui est appliqué sur le client. Es-tu certains que le poste est bien derrière cette policy et que celle ci n'est pas écrasée par une stratégie parent par exemple ? En bonne pratique je te conseille d'utiliser la section "Informations sur le support technique" qui te permettra d'ajouter une description afin de confirmer que la policy reçue est bien la bonne. Sinon, si tu sors ton poste de la stratégie (Icone K de la barre des tâches > clic-droit > désactiver la stratégie) et que tu regardes localement la classification de ton exécutable, est-il toujours dans le groupe de confiance ? Si tel n'est pas le cas, ajoute-le manuellement et effectue de nouveau tes tests. Bon courage !
  13. Mahamadi, Il peut y avoir plusieurs explications à un état critique en rouge de l'agent ou de l'antivirus (protection en temps réel non installée ou stoppée, scan non effectué depuis longtemps ...), de manière générale tu obtiendras plus de détails depuis le volet d'informations de droite lorsque tu cliques sur le poste client concerné depuis la console d'administration : 1er exemple : la connexion au poste client administré a été perdue depuis la dernière synchronisation avec le serveur KSC il y a une semaine. Vérifier que le poste est bien disponible ainsi que l'état du service de l'agent d'administration à l'aide de l'outil klnagchk : https://support.kaspersky.com/9292 Réinstaller l'agent si nécessaire. 2ème exemple : ce poste ne s'est plus synchronisé avec son serveur KSC depuis longtemps. La protection antivirus n'est pas installée. Vérifier l'état du service de l'agent d'administration à l'aide de l'outil klnagchk : https://support.kaspersky.com/9292 Réinstaller l'agent si nécessaire puis déployer la protection antivirus sur le poste cible. Sinon , je te recommande vivement de consulter les quelques articles ci-joints qui t'aideront efficacement : ==> Connexion de l'agent au serveur KSS : https://support.kaspersky.com/fr/12776#block2 ==> Statut réel d'un poste client ( protection, agent, bases, licence ...) administré par KSC : https://support.kaspersky.com/fr/13758 ==> Outils de supervision de la console : Bon courage !
  14. Bonjour Maher, tu peux partager des captures s'il te plait illustrant ces différentes détections. Merci.
  15. dans ce cas Il s'agit peut être de traces appartenant à une autre application tierce incompatible qui est à l'origine de ton blocage. Il est probable que celles ci soient passées à la trappe lors de l'installation de la version précédente KES 10 , ce n'est bien sur qu'une hypothèse. Que donne une nouvelle tentative d'installation locale de KES 11 via cette ligne de commande ? : setup.exe /pEULA=1 /pKSN=0 /pPRIVACYPOLICY=1 /pSKIPPRODUCTCHECK=1 /pSKIPPRODUCTUNINSTALL=1 /s
×
×
  • 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.