Limitations et précisions sur les cas d'utilisation

QoS

IMPORTANT

Cette fonctionnalité est en accès anticipé.

Veuillez impérativement consulter les Problèmes connus avant d'activer cette fonctionnalité ou de mettre à jour une configuration QoS existante vers une version SNS 4.3 ou supérieure.

La QoS implémentée en version SNS 4.3 présente les limitations suivantes :

  • Bande passante maximale supportée : 1Gbps,
  • Interfaces supportées :
    • Ethernet,
    • IPsec,
    • GRETAP,
    • IPsec virtuelles (VTI),
    • VLAN.
  • Les files d'attente de type PRIQ et CBQ ne sont pas compatibles entre elles et ne doivent pas être utilisées sur le même traffic shaper,
  • Les seuils définis sur les files d'attente doivent être tous en valeur absolue ou tous en pourcentage,
  • La somme de la bande passante réservée ne doit pas excéder la bande passante du traffic shaper,

  • Lorsque la QoS est activée, les flux non soumis à la QoS sont affectés par une baisse globale du débit sur le firewall SNS. Ceci est lié au fait que les flux utilisant des files d'attente de type bypass ne peuvent pas exploiter la totalité de la bande passante disponible à cause d'une gestion non optimale des architectures multi-CPU par le moteur de la QoS.

Gestion des connexions avec NAT lors d'un changement de passerelle au sein d'un objet routeur

Lors d'un changement de passerelle active au sein d'un objet routeur utilisé :

  • Soit dans du filtrage basé sur le routage (PBR),
  • Soit dans une route statique,
  • Soit comme passerelle par défaut.

Si de la translation d'adresse source par connexion (NAT) est appliquée pour les flux empruntant cet objet routeur, les paquets des connexions déjà établies sont alors redirigés vers la passerelle nouvellement active mais en présentant l'adresse IP source correspondant à l'interface de sortie de la passerelle devenue inactive.

Ces connexions s'interrompent mais peuvent néanmoins être toujours considérées comme actives par le moteur de prévention d’intrusion ce qui empêche l'établissement de nouvelles connexions. C'est le cas pour le protocole SIP, par exemple.

Un contournement consiste à purger ces connexions en suivant la procédure décrite dans l'article Established UDP connections fail after routing failover de la Base de connaissances Stormshield (anglais uniquement).

Gestion des connexions lors d'un changement de passerelle au sein d'un objet routeur utilisé dans du filtrage basé sur le routage (PBR)

Lors d'un changement de passerelle active au sein d'un objet routeur utilisé dans du filtrage basé sur le routage, les connexions en cours sont envoyées vers la route par défaut plutôt que vers la passerelle nouvellement active de l'objet routeur.

Un contournement consiste à utiliser une route statique plutôt que du PBR pour ces flux.

Firewalls équipés d'un TPM

Référence support 83580

Après une mise à jour en version 4.3 LTSB, les secrets stockés dans le TPM nécessitent d'être scellés avec les nouvelles caractéristiques techniques du système à l'aide de la commande CLI / Serverd :

SYSTEM TPM PCRSEAL tpmpassword=<TPMpassword>

Notez que dans le cas d'un cluster, cette action doit être réalisée pour les deux membres du cluster depuis le firewall actif (en ajoutant le paramètre "serial=passive" pour sceller les secrets du firewall passif depuis le firewall actif).

Pour plus d'informations sur le module TPM, reportez-vous à la section Trusted Platform Module du manuel utilisateur SNS 4.3 LTSB.

Protocole PROFINET-RT

Référence support 70045

Une mise à jour du pilote de contrôleur réseau utilisé sur les firewalls modèles SNi40, SN2000, SN3000, SN6000, SN510, SN710, SN910, SN2100, SN3100 et SN6100 autorise la gestion d'un VLAN ayant un identifiant égal à 0. Ceci est nécessaire pour le fonctionnement du protocole Industriel PROFINET-RT.

En revanche, les modules réseau IX (modules 2x10Gbps et 4x10Gbps fibre équipés du micro-composant INTEL 82599) et IXL (voir la liste des modules concernés) ne bénéficient pas de cette mise à jour et ne peuvent donc pas gérer le protocole PROFINET-RT.

VPN IPsec

Optimisation de la répartition des opérations de chiffrement / déchiffrement

Dans une configuration avec un tunnel IPsec unique au sein duquel transitent plusieurs flux, l'activation du mécanisme d'optimisation des opérations de chiffrement / déchiffrement peut entraîner un déséquencement des paquets et peut provoquer des rejets sur le destinataire des paquets chiffrés suivant la taille de la fenêtre anti-rejeu configurée.

Interruption de négociation d'une phase 2

Le moteur de gestion IPsec Charon, utilisé dans le cadre de politiques IKEv1, peut interrompre tous les tunnels avec le même correspondant si une seule phase 2 échoue.

Cela est dû à l'absence de notification de la part du correspondant suite à un échec de négociation lié à une différence d'extrémités de trafic.

Comme indiqué plus haut, le comportement du moteur de gestion IPsec Racoon a été modifié en version 4.1.0 afin que cela ne se produise pas dans le cadre d'un tunnel Racoon <=> Charon.

Vous pouvez néanmoins être confronté à ce problème dans le cas où le moteur de gestion IPsec Charon négocie avec un équipement qui n'émet pas de notification d'échec.

Contraintes IPsec

L'utilisation de correspondants IKEv1 et IKEv2 au sein d'une même politique IPsec nécessite de respecter plusieurs contraintes :

  • Le mode de négociation "agressif" n'est pas autorisé pour un correspondant IKEv1 avec authentification par clé pré-partagée. Un message d'erreur est affiché lors de la tentative d'activation de la politique IPsec.
  • La méthode d'authentification "Hybride" ne fonctionne pas pour un correspondant nomade IKEv1.
  • Les correspondants de secours sont ignorés. Un message d'avertissement est affiché lors de l'activation de la politique IPsec.
  • L'algorithme d'authentification "non_auth" n'est pas supporté pour un correspondant IKEv1. Dans un tel cas, la politique IPsec ne peut pas être activée.
  • Dans une configuration mettant en œuvre du NAT-T (NAT-Traversal - Passage du protocole IPsec au travers d'un réseau réalisant de la translation d'adresses dynamique), il est impératif de définir l'adresse IP translatée comme identifiant d'un correspondant utilisant l'authentification par clé pré-partagée et pour lequel un ID local sous la forme d'une adresse IP aurait été forcé.

PKI

La présence d’une liste des certificats révoqués (CRL) n’est pas requise. Si aucune CRL n’est trouvée pour l’autorité de certification (CA), la négociation sera autorisée.

La présence de CRL peut être rendue obligatoire à l'aide du paramètre "CRLRequired=1" de la commande en ligne (CLI) CONFIG IPSEC UPDATE. Lorsque ce paramètre est activé, il est nécessaire de disposer de toutes les CRL de la chaîne de certification.

Référence support 37332

DPD (Dead Peer Detection)

La fonctionnalité VPN dite de DPD (Dead Peer Detection) permet de vérifier qu’un correspondant est toujours opérationnel en envoyant des messages ISAKMP.

Si un firewall est répondeur d'une négociation IPsec en mode principal, et a configuré le DPD en « Inactif », ce paramètre sera forcé en « passif » pour répondre aux sollicitations DPD du correspondant. En effet, pendant cette négociation IPsec, le DPD est annoncé avant d'avoir identifié le correspondant, et donc avant de connaître si les requêtes DPD peuvent être ignorées pour ce correspondant.

Ce paramètre n’est pas modifié en mode agressif, car dans ce cas le DPD est négocié lorsque le correspondant est déjà identifié, ou dans le cas où le firewall est initiateur de la négociation.

VPN IPsec IKEv2

Le protocole EAP (Extensible Authentication Protocol) ne peut pas être utilisé pour l’authentification de correspondants IPsec utilisant le protocole IKEv2.

Dans une configuration mettant en œuvre un tunnel IPsec basé sur le protocole IKEv2 et de la translation d’adresse, l’identifiant présenté par la machine source au correspondant distant pour établir le tunnel correspond à son adresse IP réelle et non à son adresse IP translatée. Il est donc conseillé de forcer l’identifiant local à présenter (champ Local ID dans la définition d’un correspondant IPsec IKEv2) en utilisant l’adresse translatée (si celle-ci est statique) ou un FQDN porté par le firewall source.

Correspondants de secours

Il n’est plus possible de définir une configuration de secours pour les correspondants IPsec. Pour mettre en œuvre une configuration IPsec redondante, il est conseillé d’utiliser des interfaces virtuelles IPsec et des objets routeurs dans les règles de filtrage (PBR).

Réseau

Modems 4G

La connectivité du firewall à un modem USB 4G nécessite l'utilisation d'un équipement de marque HUAWEI dans la liste suivante :

  • E3372h-153,

  • E8372h-153,

  • E3372h-320.

D'autres modèles de clés pourraient fonctionner, mais ils n'ont pas été testés.

Routage - Réseau directement connecté à une interface du firewall

Référence support 79503

Lorsqu'un réseau est directement connecté à une interface du firewall, le firewall crée une route implicite d'accès à ce réseau. Cette route est appliquée en amont des règles de PBR (Policy Based Routing - Filtrage par politique) : le routage par PBR est donc ignoré pour ces réseaux directement connectés.

Protocoles Spanning Tree (RSTP / MSTP)

Les firewalls Stormshield Network ne supportent pas les configurations multi-régions MSTP. Un firewall implémentant une configuration MSTP et positionné en interconnexion de plusieurs régions MSTP pourrait ainsi rencontrer des dysfonctionnements dans la gestion de sa propre région.

Un firewall ayant activé le protocole MSTP, et ne parvenant pas à dialoguer avec un équipement qui ne supporte pas ce protocole, ne bascule pas automatiquement sur le protocole RSTP.

De par leur fonctionnement, les protocoles RSTP et MSTP ne peuvent pas être activés sur les interfaces de type VLAN et modems PPTP/PPPoE.

Interfaces

Sur les firewalls modèle SN160(W) et SN210(W), la présence d’un switch interne non administrable entraîne l’affichage permanent des interfaces réseau du firewall en état « up », même lorsque celles-ci ne sont pas connectées physiquement au réseau.

Les interfaces du firewall (VLAN, interfaces PPTP, interfaces agrégées [LACP], etc.) sont rassemblées dans un pool commun à l’ensemble des modules de configuration. Lorsqu’une interface précédemment utilisée dans un module est libérée, elle ne devient réellement réutilisable pour les autres modules qu’après un redémarrage du firewall.

La suppression d'une interface VLAN provoque un ré-ordonnancement de ce type d'interfaces au redémarrage suivant. Si ces interfaces sont référencées dans la configuration du routage dynamique ou supervisées via la MIB-II SNMP, ce comportement induit un décalage dans l'ordre des interfaces et peut potentiellement provoquer un arrêt de service. Il est donc fortement conseillé de désactiver une interface VLAN non utilisée plutôt que de la supprimer.

L'ajout d'interfaces Wi-Fi dans un bridge est en mode expérimental et ne peut pas s'effectuer via l'interface Web d'administration.

Sur les modèles SN160(W), une configuration comportant plusieurs VLAN inclus dans un bridge n’est pas supportée.

Une configuration avec un bridge incluant plusieurs interfaces non protégées et une route statique sortant de l'une de ces interfaces (autre que la première) n'est pas supportée.

Routage dynamique Bird

Dans les configurations utilisant le protocole BGP avec de l'authentification, il est nécessaire d'utiliser la directive "source address <ip>;". Pour de plus amples informations sur la configuration de Bird, veuillez consulter la Note Technique "Routage dynamique Bird".

Lorsque le fichier de configuration de Bird est édité depuis l’interface d’administration Web, l’action Appliquer envoie effectivement cette configuration au firewall. En cas d’erreur de syntaxe, la configuration n'est pas prise en compte et un message d’avertissement indiquant le numéro de ligne en erreur informe de la nécessité de corriger la configuration. En revanche, une configuration erronée envoyée au firewall sera prise en compte au prochain redémarrage du service Bird ou du firewall, empêchant alors le chargement correct du service Bird.

Routage par politique de filtrage

Si une remise en configuration d’usine du firewall (defaultconfig) est réalisée suite à une migration de la version 2 vers la version 3 puis vers la version 4, l’ordre d’évaluation du routage est modifié et le routage par politique de filtrage [PBR] devient prioritaire (routage par politique de filtrage > routage statique > routage dynamique >…> routage par défaut). En revanche, en l’absence de remise en configuration d’usine du firewall, l’ordre d’évaluation reste inchangé par rapport à la version 1 (routage statique > routage dynamique > routage par politique de filtrage [PBR] > routage par interface > routage par répartition de charge > routage par défaut).

Système

Référence support 78677

Cookies générés pour l’authentification multi-utilisateurs

Suite à l’implémentation d'une nouvelle politique de sécurité sur les navigateurs Web du marché, l’authentification multi-utilisateurs SNS n’est plus fonctionnelle dans le cas où un site non sécurisé (via HTTP) est consulté.

Ce comportement aboutit à l'affichage d’un message d'erreur ou d'un avertissement selon le navigateur Web utilisé, et est lié au fait que les cookies d’authentification du proxy ne peuvent pas utiliser l'attribut "Secure" conjointement à l’attribut “SameSite” dans le cadre d'une connexion non sécurisée HTTP.

Pour rétablir la navigation sur ces sites, une opération manuelle doit être effectuée dans la configuration du navigateur Web.
En savoir plus

Référence support 51251

Serveur DHCP

Lors de la réception d'une requête DHCP de type INFORM émise par un client Microsoft, le firewall envoie au client son propre serveur DNS primaire accompagné du serveur DNS secondaire paramétré dans le service DHCP. Il est conseillé de désactiver le protocole Web Proxy Auto-Discovery Protocol (WPAD) sur les clients Microsoft afin d'éviter ce type de requêtes.

Référence support 3120

Configuration

Le client NTP des firewalls ne supporte la synchronisation qu’avec les serveurs utilisant la version 4 du protocole.

Restauration de sauvegarde

Il n'est pas possible de restaurer une sauvegarde de configuration réalisée sur un firewall dont la version du système était postérieure à la version courante. Ainsi, par exemple, il n'est pas possible de restaurer une configuration sauvegardée en 4.0.1, si la version courante du firewall est la 3.9.2.

Objets dynamiques

Les objets réseau en résolution DNS automatique (objets dynamiques), pour lesquels le serveur DNS propose un type de répartition de charge round-robin, provoquent le rechargement de la configuration des modules uniquement si l'adresse actuelle n'est plus présente dans les réponses.

Objets de type Nom DNS (FQDN)

Les objets de type Nom DNS ne peuvent pas être membres d'un groupe d'objets.

Une règle de filtrage ne peut s'appliquer qu'à un unique objet de type Nom DNS. Il n'est donc pas possible d'y ajouter un second objet de type FQDN ou un autre type d'objet réseau.

Les objets de type Nom DNS ne peuvent pas être utilisés dans une règle de NAT. Notez qu'aucun avertissement n'est affiché lorsqu'une telle configuration est réalisée.

Lorsque aucun serveur DNS n'est disponible, l'objet de type Nom DNS ne contiendra que l'adresse IPv4 et / ou IPv6 renseignée lors de sa création.

Si un nombre important de serveurs DNS est renseigné dans le firewall, ou si de nouvelles adresses IP concernant un objet de type Nom DNS sont ajoutées au(x) serveur(s) DNS, l'apprentissage de l'ensemble des adresses IP de l'objet peut nécessiter plusieurs requêtes DNS de la part du firewall (requêtes espacées de 5 minutes).

Si les serveurs DNS renseignés sur les postes clients et sur le firewall diffèrent, les adresses IP reçues pour un objet de type Nom DNS peuvent ne pas être identiques. Ceci peut, par exemple, engendrer des anomalies de filtrage si l'objet de type DNS est utilisé dans la politique de filtrage.

Journaux de filtrage

Lorsqu’une règle de filtrage fait appel au partage de charge (utilisation d’un objet routeur), l’interface de destination référencée dans les journaux de filtrage n’est pas forcément correcte. En effet, les traces de filtrage étant écrites dès qu’un paquet réseau correspond aux critères de cette règle, l’interface de sortie n’est alors pas encore connue. C’est donc la passerelle principale qui est systématiquement reportée dans les journaux de filtrage.

Haute Disponibilité

Migration

Lors de la mise à jour de SNS v3 vers SNS v4 du membre passif d'un cluster, les tunnels IPsec déjà établis sont renégociés. Ceci est un comportement normal.

Interaction HA en mode bridge et switches

Dans un environnement avec un cluster de firewalls configurés en mode bridge, le temps de bascule du trafic constaté est de l’ordre de 10 secondes. Ce délai est lié au temps de bascule d’1 seconde auquel vient s’ajouter le temps de réapprentissage des adresses MAC par les switches qui sont directement connectés aux firewalls.

Routage par politique

Une session routée par la politique de filtrage peut être perdue en cas de bascule du cluster.

Modèles

La Haute Disponibilité basée sur un groupe (cluster) de firewalls de modèles différents n’est pas supportée.

VLAN dans un agrégat d'interfaces et lien HA

Référence support 59620

Le choix d'un VLAN appartenant à un agrégat d'interfaces (LACP) comme lien de haute disponibilité n'est pas autorisé. En effet, cette configuration rend le mécanisme de haute disponibilité inopérant sur ce lien: l'adresse MAC attribuée à ce VLAN sur chacun des firewalls est alors 00:00:00:00:00:00.

Support IPv6

En version SNS 4, voici les principales fonctionnalités non disponibles pour le trafic IPv6 :

  • Le trafic IPv6 au travers de tunnels IPsec basés sur des interfaces IPsec virtuelles (VTI),
  • La translation d'adresses IPv6 (NATv6),
  • Inspections applicatives (Antivirus, Antispam, Filtrage URL, Filtrage SMTP, Filtrage FTP, Filtrage SSL),
  • L’utilisation du proxy explicite,
  • Le cache DNS,
  • Les tunnels VPN SSL portail,
  • Les tunnels VPN SSL,
  • L’authentification via Kerberos,
  • Le Management de Vulnérabilités,
  • Les interfaces modems (en particulier les modems PPPoE).

Haute Disponibilité

Dans le cas où un Firewall est en Haute Disponibilité et a activé la fonctionnalité IPv6, les adresses MAC des interfaces portant de l'IPv6 (autres que celles du lien HA) doivent impérativement être définies en configuration avancée. En effet, les adresses de lien local IPv6 étant dérivées de l'adresse MAC, ces adresses seront différentes, entraînant des problèmes de routage en cas de bascule.

Notifications

IPFIX

Les événements envoyés via le protocole IPFIX n'incluent ni les connexions du proxy, ni les flux émis par le firewall lui-même (exemple : flux ESP pour le fonctionnement des tunnels IPsec).

Rapports d’activités

La génération des rapports se base sur les traces (logs) enregistrées par le firewall et celles-ci sont générées à la clôture des connexions. En conséquence, les connexions toujours actives (exemple : tunnel IPsec avec translation) ne seront pas affichées dans les statistiques affichées par les rapports d’activités.

Les traces générées par le firewall dépendent du type de trafic qui ne nomme pas forcément de la même façon les objets (srcname et dstname). Pour éviter de multiples représentations d’un même objet dans les rapports, il est conseillé de donner à l’objet créé dans la base du firewall, le même nom que celui associé via la résolution DNS.

Prévention d’intrusion

Protocole GRE et tunnels IPsec

Le déchiffrement de flux GRE encapsulés dans un tunnel IPsec génère à tort l’alarme « Usurpation d’adresse IP sur l’interface IPsec ». Il est donc nécessaire de configurer l’action à passer sur cette alarme pour faire fonctionner ce type de configuration.

Analyse HTML

Le code HTML réécrit n’est pas compatible avec tous les services web (apt-get, Active Update) parce que l’en-tête HTTP « Content-Length » a été supprimé.

Référence support 35960

Préserver le routage initial

L’option permettant de préserver le routage initial sur une interface n'est pas compatible avec les fonctionnalités pour lesquelles le moteur de prévention d’intrusion doit créer des paquets :

  • la réinitialisation des connexions lors de la détection d'une alarme bloquante (envoi de paquet RESET),
  • la protection SYN Proxy,
  • la détection du protocole par les plugins (règles de filtrage sans protocole spécifié),
  • la réécriture des données par certains plugins tels que les protections web 2.0, FTP avec NAT, SIP avec NAT et SMTP.

NAT

Support H323

Le support des opérations de translation d'adresses du protocole H323 est rudimentaire, en particulier : il ne supporte pas les cas de contournement du NAT par les gatekeeper (annonce de l'adresse autre que source ou destination de la connexion).

Messagerie instantanée

Le NAT sur les protocoles de messagerie instantanée n’est pas supporté.

Proxies

Référence support 35328

Proxy FTP

Si l’option « conserver l'adresse IP source originale » est activée sur le proxy FTP, le rechargement de la politique de filtrage entraîne l’interruption des transferts FTP en cours (en upload ou download).

Référence support 31715

Filtrage URL

Le filtrage différencié par utilisateur n’est pas possible au sein d’une politique de filtrage URL. Il est toutefois possible d’appliquer des règles de filtrage particulières (inspection applicative) et d'associer à chacune un profil de filtrage URL différent.

Filtrage

Interface de sortie

Une règle de filtrage précisant une interface de sortie incluse dans un bridge, et qui ne serait pas la première interface de ce bridge, n’est pas exécutée.

Filtrage Multi-utilisateur

Il est possible de permettre l’authentification Multi-utilisateur à un objet réseau (plusieurs utilisateurs authentifiés sur une même adresse IP) en renseignant l’objet dans la liste des Objets Multi-utilisateurs (Authentification > Politique d’authentification).

Les règles de filtrage avec une source de type user@objet (sauf any ou unknow@object), avec un protocole autre qu’HTTP, ne s’appliquent pas à cette catégorie d’objet. Ce comportement est inhérent au mécanisme de traitement des paquets effectué par le moteur de prévention d’intrusion. Le message explicite avertissant l’administrateur de cette limitation est le suivant : « Cette règle ne peut identifier un utilisateur connecté sur un objet multi-utilisateur ».

Géolocalisation et réputation des adresses IP publiques

Lorsqu'une règle de filtrage précise des conditions de géolocalisation et de réputation d'adresses publiques, il est nécessaire que ces deux conditions soient remplies pour que la règle soit appliquée.

Réputation des machines

Si les adresses IP des machines sont distribuées via un serveur DHCP, la réputation d'une machine dont l'adresse aurait été reprise par une autre machine sera également attribuée à celle-ci. Dans ce cas, la réputation de la machine peut être réinitialisée à l'aide de la commande CLI monitor flush hostrep ip = host_ip_address.

Authentification

Portail captif - Page de déconnexion

La page de déconnexion du portail captif ne fonctionne que pour les méthodes d'authentification basées sur des mots de passe.

SSO Agent

La méthode d’authentification Agent SSO se base sur les évènements d’authentification collectés par les contrôleurs de domaine Windows. Ceux-ci n’indiquant pas l’origine du trafic, la politique d’authentification ne peut être spécifiée avec des interfaces.

Référence support 47378

Les noms d’utilisateurs contenant les caractères spéciaux suivants : " <tab> & ~ | = * < > ! ( ) \ $ % ? ' ` @ <espace> ne sont pas pris en charge par l’Agent SSO. Le firewall ne recevra donc pas les notifications de connexions et déconnexions relatives à ces utilisateurs.

Domaines Microsoft Active Directory multiples

Dans le cadre de domaines Microsoft Active Directory multiples liés par une relation d'approbation, il est nécessaire de définir dans la configuration du firewall un annuaire Active Directory et un agent SSO pour chacun de ces domaines.

Les méthodes SPNEGO et Kerberos ne peuvent pas être utilisées sur plusieurs domaines Active Directory.

Le protocole IKEv1 nécessite l'emploi de l'authentification étendue (XAUTH).

Annuaires multiples

Les utilisateurs ne peuvent s'authentifier que sur l'annuaire par défaut via les méthodes certificat SSL et Radius.

Méthode CONNECT

L’authentification multi-utilisateur sur une même machine en mode Cookie, ne supporte pas la méthode CONNECT (protocole HTTP). Cette méthode est généralement utilisée avec un proxy explicite pour les connexions HTTPS. Pour ce type d’authentification, il est recommandé d’utiliser le mode « transparent ». Pour plus d’informations, consultez l’aide en ligne à l’adresse documentation.stormshield.eu, section Authentification.

Utilisateurs

La gestion d'annuaires LDAP multiples impose une authentification précisant le domaine d'authentification : user@domain.

Le caractère spécial « espace » dans les identifiants (« login ») des utilisateurs n’est pas supporté.

Déconnexion

La déconnexion d’une authentification ne peut se faire que par la méthode utilisée lors de l’authentification. Par exemple, un utilisateur authentifié avec la méthode Agent SSO ne pourra pas se déconnecter via le portail d'authentification, car l'utilisateur doit fournir pour la déconnexion, un cookie n’existant pas dans ce cas.

Comptes temporaires

Lors de la création d'un compte temporaire, le firewall génère automatiquement un mot de passe d'une longueur de 8 caractères. Dans le cas d'une politique globale de mots de passe imposant une longueur supérieure à 8 caractères, la création d'un compte temporaire génère alors une erreur et le compte ne peut pas être utilisé pour s'authentifier.

L'utilisation des comptes temporaires nécessite donc une politique de mots de passe limités à 8 caractères maximum.

Management des vulnérabilités

Référence support 28665

L'inventaire d'applications réalisé par le Management des vulnérabilités se base sur l'adresse IP de la machine initiant le trafic pour indexer les applications.

Le cas de machines ayant une adresse IP partagée par plusieurs utilisateurs, par exemple un proxy HTTP, un serveur TSE ou encore un routeur réalisant du NAT dynamique de la source, peuvent entraîner une charge importante sur le module. Il est donc conseillé de mettre les adresses de ces machines dans la liste d'exclusion (éléments non supervisés).