Pourquoi les utilisateurs déconnectés se connectent-ils GlobalProtect à partir d’une VPN RDP station au moment de la RDP perte de connexion ?

Pourquoi les utilisateurs déconnectés se connectent-ils GlobalProtect à partir d’une VPN RDP station au moment de la RDP perte de connexion ?

18104
Created On 01/25/23 13:26 PM - Last Modified 01/31/23 00:20 AM


Environment


  • GlobalProtect client exécuté sur une machine Bureau à distance Windows.
  • Les utilisateurs se connectent à l’environnement RDP pour établir GlobalProtect des connexions à partir de là.

 

Answer


  • Aucune période de grâce n’est accordée aux utilisateurs lorsqu’ils se reconnectent à la session perdue RDP par défaut - ils sont déconnectés de la passerelle au moment de la RDP perte de connexion.
  • Windows n’influence pas ce comportement, la configuration doit être ajustée au niveau du portail pour donner plus de temps aux utilisateurs pour se reconnecter sans perdre la GP connexion.
  • L’élément de configuration qui contrôle ce comportement est appelé « User Switch Tunnel Rename Timeout ». Veuillez consulter le guide d’administration ci-joint pour plus de détails dans la section « Informations supplémentaires ».
  • Les deux scénarios ci-dessous décrivent les événements qui se produisent lorsque l’utilisateur se déconnecte de la RDP session alors que celle-ci GlobalProtect VPN est restée connectée. Le premier scénario décrit la situation dans laquelle l’utilisateur pourra se reconnecter sans perdre la GP VPN connexion, tandis que le second scénario décrit exactement le contraire.
 
  1. Le délai d’expiration du changement de nom du tunnel de changement d’utilisateur (sec) est configuré pendant 90 secondes lorsque l’utilisateur pourra se reconnecter.

     
    GP détecte, cet utilisateur a été déconnecté de la RDP station (session = connexion utilisateur dans les termes Windows)
    (P3096-T3100) Débogage( 348): 12/09/22 08:24:02:000 Changement de session reçu, type d’événement 4, session 2
    (P3096-T3100) Infos (1571): 12/09/22 08:24:02:374 verrouiller la session 2
    (P3096-T4272) Infos ( 531): 12/09/22 08:24:02:562 msgtype = déconnexion
     
     
    GP configure la période de grâce à laquelle l’utilisateur peut se reconnecter sans avoir besoin de se reconnecter RDP GP
    (P3096-T4272) Débogage(3785): 12/09/22 08:24:02:562 Maintenant est 1670570642, l’heure de la dernière connexion utilisateur est 1670570642
    (P3096-T4272) Débogage(3789): 12/09/22 08:24:02:562 tDelta est 0, délai de grâce est 90
    (P3096-T4272) Débogage(10827): 12/09/22 08:24:02:562 Début du thread de surveillance de la période de grâce
     
     
    GP crée et démarre un thread responsable de la rétention de la RDP connexion
    (P3096-T4272) Débogage( 25): 12/09/22 08:24:02:562 Créer un thread 0x83c avec thread ID 8432
    (P3096-T8432) Infos (10841): 12/09/22 08:24:02:562 Démarrer CPanMSService::RdpGracePeriodMonitorThread
    (P3096-T8432) Débogage(10844): 12/09/22 08:24:02:562 RdpGracePeriodMonitorThread démarre
     
     
    L’utilisateur se reconnecte à RDP
    (P3096-T3100) Débogage( 348): 12/09/22 08:25:17:335 Changement de session reçu, type d’événement 3, session 2
     
     
    GP vérifie si l’utilisateur est réellement connecté pendant la période de grâce
    (P3096-T4272) Débogage(3785): 12/09/22 08:25:18:515 Maintenant est 1670570718, l’heure de la dernière connexion utilisateur est 1670570642
    (P3096-T4272) Débogage(3789): 12/09/22 08:25:18:515 tDelta est 76, délai de grâce est 90 // il a fallu 76 secondes à l’utilisateur pour se reconnecter à RDP, ce qui est dans la période de grâce
    (P3096-T4272) Débogage(2961): 12/09/22 08:25:18:515 Envoyer un message de compte à rebours de la période de grâce à PanGPA
    (P3096-T4272) Debug(1969): 12/09/22 08:25:18:515 Envoyer une réponse au client pour la demande switch-on-rename-grace-period.
 
 
2. Le délai de renommage du tunnel de changement d’utilisateur (sec) est configuré pour 60 secondes et l’utilisateur ne pourra pas se connecter à temps, il sera donc déconnecté de la passerelle
 
GP passe par la même routine que ci-dessus avec ces différences
(P3096-T4272) Débogage(3789): 12/08/22 22:00:03:127 tDelta est égal à 0, délai de grâce est de 60
(P3096-T9060) Débogage(10872): 12/08/22 22:01:03:139 Expiration de la période de grâce
(P3096-T9060) Débogage(10874): 12/08/22 22:01:03:139 Déconnecter le tunnel car la période de grâce expire.
(P3096-T9060) Debug(7237): 12/08/22 22:01:03:139 --Set state to Disconnecting...
(P3096-T9060) Débogage ( 853): 12/08/22 22:01:03:139 déconnexion VPN
(P3096-T9060) Débogage(1574): 12/08/22 22:01:03:249 Déconnecter l’interface virtuelle
(P3096-T9060) Débogage( 692): 12/08/22 22:01:03:687 DisconnectVPN appelé
(P3096-T9060) Débogage(3452): 12/08/22 22:01:03:687 définir le pilote connecté comme false
(P3096-T9060) Infos (2303): 12/08/22 22:01:03:687 déconnexion: ----informations détaillées sur l’utilisateur-----
(P3096-T9060) Débogage(2385): 12/08/22 22:01:03:718 Passerelle déconnectée gateway.domain.com
 
 
Si vous exécutez la capture de paquets sur la station au moment du test et que vous ne vous connectez pas pendant la période de grâce, Wireshark affichera une boîte de message sur l RDP 'adaptateur déconnecté GP . Cela correspond au journal « Déconnecter l’interface virtuelle ».


 

Additional Information


https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-web-interface-help/globalprotect/network-globalprotect-portals/globalprotect-portals-agent-configuration-tab/globalprotect-portals-agent-app-tab
Other users also viewed:
Actions
  • Print
  • Copy Link

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

Choose Language