Dépannage ID User-cache timeout

Dépannage ID User-cache timeout

26906
Created On 03/23/21 14:00 PM - Last Modified 06/12/23 13:58 PM


Symptom


Les utilisateurs ont des problèmes de connectivité en raison de ne plus correspondre aux stratégies de sécurité qui sont configurées pour des comptes d’utilisateurs spécifiques. Les journaux de trafic montrent que le trafic correspondait aux bonnes stratégies au début et que les informations utilisateur étaient remplies, mais après un certain temps, le trafic a commencé à frapper de mauvaises stratégies et aucune information utilisateur n’a été remplie.

Cause


Cela est probablement dû au délai d’attente utilisateur-cache,ID qui atteint la valeur de délai d’attente avant qu’une nouvelle IP cartographie utilisateur ne soit générée. Cela ferait que les utilisateurs particuliers n’ont plus un IP à la cartographie utilisateur sur le firewall .

Resolution


IPLorsqu’une cartographie utilisateur est générée, elle est disponible avec une valeur de délai d’attente, qui est visible sous l’onglet Moniteur -> Journaux -> utilisateur ID  sur l’interface utilisateur web.

Image ajoutée par l'utilisateur

Ce délai d’attente dicte combien de temps la cartographie sera stockée dans le cache jusqu’à ce qu’elle soit supprimée. En outre, il est actualisé si un nouvel utilisateur-événementID traité. Vous pouvez afficher le courant des TTL entrées IP de cartographie utilisateur en utilisant ces commandes CLI :
show user ip-user-mapping all
show user ip-user-mapping ip <ip>

S’il vous plaît trouver ci-dessous quelques sorties d’échantillon:
   Image ajoutée par l'utilisateur

Pour tracer le problème jusqu’à la mise à jour du cache:

1. Deux journaux doivent être filtrés par la source de l’utilisateur IP :
  • Surveiller l’onglet > journaux > trafic
  • Surveiller l’onglet > journaux > utilisateur ID
2. Dans les journaux de trafic, trouver la première entrée où l’utilisateur a commencé à frapper la règle involontaire. Dans la plupart des environnements, cela serait considéré comme policyune entrée de journal de refus pour la règle interzone-défaut, ou une règle de refus fourre-tout configurée manuellement. Vous verraient également cela comme la première entrée où le champ Utilisateur Source commence à être vide.

3. Notez l’heure àù le journal a été généré, puis passez sur les journaux ID utilisateur.
  • Trouvez la dernière entrée avant que le problème ne se produise pour l’adresse de cet IP utilisateur
  • Notez l’heure de cette entrée et ajoutez le délai d’attente pour cette entrée.
4. Maintenant, comparez le résultat de cela à l’heure du journal de trafic qui a été noté. Si le résultat est plus tôt que le temps du journal de trafic, il montre que la IP cartographie utilisateur à l’utilisateur expiré comme prévu et le délai d’attente du cache doit être ajusté.

Image ajoutée par l'utilisateur

Par exemple :
  • Dans le journal de trafic, la première entrée à avoir un utilisateur source vierge était 03/23 06:37:19.
  • Dans le journal ID utilisateur, vous voyez une entrée au 23/03 06:32:18 avec un délai d’attente de 300 (5 minutes).
06:32:18 + 5 minutes = 06:37:18 devrait être le temps prévu que l’utilisateur de IP mappage cache TTL atteint 0 et a été supprimé. C’est 1 seconde avant que l’utilisateur source ne s’affiche vide dans les journaux, ce qui montre que l’utilisateur IP à la cartographie doit avoir expiré.
 
En conclusion :

La cause du problème dans ce cas est que les événements qui génèrent une IP cartographie utilisateur se produisent moins fréquemment que le délai d’attente du cache.
Other users also viewed:
Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000001Uu5CAE&lang=fr&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language