GlobalProtect sur Windows : Le tunnel pré-Logon ne parvient pas à s’établir par intermittence
70244
Created On 03/03/21 18:09 PM - Last Modified 04/19/21 16:46 PM
Symptom
GlobalProtect Pré-Logon Tunnel, comme son nom l’indique, est un tunnel créé entre le point final et la GlobalProtect GlobalProtect passerelle « avant » l’utilisateur se connecte au point final. Cet article décrit un problème que l’on pourrait rencontrer lors du déploiement de la configuration pré-logon dans les PC Windows. Le flux de travail d’établissement de tunnel pré-logon dans Windows est le suivant :
- Une fois windows terminé le démarrage, GlobalProtect le service (PanGPS) commence. PanGPS identifie que Pre-Logon est activé en fonction du paramètre de registre et démarre un thread Pré-Logon.
- De même, lorsque toutes les sessions utilisateur sont terminées, c’est-à-dire lorsque l’utilisateur Windows se déconnecte, Windows informe PanGPS, ce qui donne le coup d’envoi d’un thread Pré-Logon.
- L’ensemble de l’établissement pré-Logon Tunnel est géré par PanGPS et doit être terminé avant que Windows informe PanGPS d’une session utilisateur.
- Dès que PanGPS se renseigne sur un événement Logon utilisateur, il procède à la fin du thread Pré-Logon. Naturellement, il y a deux résultats :
- Si le tunnel pré-logon est établi au moment où Windows informe PanGPS d’une session utilisateur, alors le tunnel pré-logon est conservé et le thread pré-logon est terminé.
- Si le tunnel pré-logon est en cours de négociation lorsque Windows informe PanGPS d’une session utilisateur, l’établissement du tunnel pré-logon est soit avorté, soit déconnecté brusquement et le thread pré-logon est terminé.
- Une fois l’événement de connexion utilisateur terminé, selon la méthode Connect et la valeur « Pre-Logon Tunnel Rename Timeout », soit le tunnel pré-logon est conservé pendant que le tunnel utilisateur est établi et gracieusement rebaptisé tunnel utilisateur, soit le tunnel pré-logon est terminé et le tunnel utilisateur est établi.
Lorsque la séquence d’événements suit un modèle normal et panGPS est donné suffisamment de temps avant l’événement de connexion de l’utilisateur, qui est généralement moins d’une minute, puis Pré-Logon Tunnel s’établira régulièrement. Cependant, nous observons un problème où le tunnel pré-Logon ne parvient pas à s’établir par intermittence, même si l’utilisateur ne s’est pas encore connecté au système.Dans les sections suivantes, nous passerons en revue les différentes étapes de fonctionnement pour nous aider à identifier le problème.
Dans un scénario de travail, la séquence suivante d’événements est observée [comme on le voit dans le fichier PanGPS.log]:
Une fois que les bottes sont en PC place:
(P5452-T5876)Info ( 156): 03/03/21 14:03:15:292 ####################### Start PanGPS service (ver: 5.2.5-66) ####################### (P5452-T7296)Info (10158): 03/03/21 14:03:17:173 PrelogonThread starts (P5452-T7296)Debug(2377): 03/03/21 14:03:17:173 ----portal processing starts---- (P5452-T7296)Debug(6897): 03/03/21 14:03:17:252 ----Portal Pre-login starts---- (P5452-T7296)Debug(8260): 03/03/21 14:03:17:454 portal status is Connected (P5452-T7324)Debug(5473): 03/03/21 14:03:17:600 ----Network Discover starts---- (P5452-T7324)Info (1385): 03/03/21 14:03:26:844 CPanGatewayList::PickGatewayBaseOnWeight, PAN_NEW_GATEWAY_SELECTOR, chose prefered gateway index =7, gateway is Amsterdam (P5452-T7324)Debug(3502): 03/03/21 14:03:26:848 ----Gateway Pre-login starts---- (P5452-T7324)Debug(3909): 03/03/21 14:03:27:123 ----Gateway Login starts---- (P5452-T7324)Debug(2645): 03/03/21 14:03:27:500 ----Tunnel creation starts---- (P5452-T7324)Debug(6849): 03/03/21 14:03:31:384 --Set state to Connected
Une fois que l’utilisateur se connecte :
(P5452-T5456)Debug(1534): 03/03/21 14:25:41:344 Session 1, username roadrunner. (P5452-T5456)Debug(1543): 03/03/21 14:25:41:344 Session 1, domain name ACME. (P5452-T5456)Info (1578): 03/03/21 14:25:42:017 User acme\roadrunner logs in on session 1 (P5452-T7160)Info (10231): 03/03/21 14:26:13:294 PrelogonThread exits (P5452-T7284)Debug(2444): 03/03/21 14:26:13:294 User just logs in (P5452-T7284)Debug(2377): 03/03/21 14:26:13:851 ----portal processing starts---- ... and so on
Dans le scénario de non-travail, la séquence suivante peut être observée [comme on le voit dans le fichier PanGPS.log]
Ici, dès que PC les bottes suivies par le démarrage du processus PanGPS, Windows informe que la session utilisateur a été créée et que la session a été verrouillée. Avec cela, l’établissement pré-Logon Tunnel ne peut pas se produire parce que PanGPS en apprend davantage sur une session utilisateur active. Ce que nous savons cependant, c’est que l’utilisateur ne s’est pas connecté officiellement, c’est-à-dire que l’utilisateur n’a pas encore tenté de se connecter en tapant les informations d’identification :
(T4456)Info ( 144): 02/24/21 18:27:37:334 ####################### Start PanGPS service (ver: 5.2.5-66) ####################### (T5192)Info (9835): 02/24/21 18:27:38:537 PrelogonThread starts (T3244)Debug(1416): 02/24/21 18:27:47:287 First logon user. (T3244)Debug(1467): 02/24/21 18:27:47:303 Session 1, username roadrunner. (T3244)Debug(1476): 02/24/21 18:27:47:303 Session 1, domain name ACME. (T3244)Debug( 302): 02/24/21 18:27:55:678 Received session change, event type 7, session 1 (T3244)Info (1556): 02/24/21 18:27:55:678 lock off session 1 (T5192)Debug(4492): 02/24/21 18:28:05:459 Prelogon flag is 1 (T5192)Debug(4470): 02/24/21 18:28:05:459 Start ProcessServerPortal tiggered by prelogon flag (T5192)Info (4107): 02/24/21 18:28:05:459 UpdatePrelogonStateForSSO() - Pre-logon tunnel state = Connecting (T5192)Debug(2233): 02/24/21 18:28:05:740 ----portal processing starts---- (T5192)Debug(6682): 02/24/21 18:28:07:006 ----Portal Pre-login starts---- (T5192)Debug(1244): 02/24/21 18:28:10:240 set certname to none-selected (T5192)Debug(6827): 02/24/21 18:28:10:240 prelogin to portal result is (null) (T5192)Debug(7123): 02/24/21 18:28:10:240 Failed to pre-login to the portal globalprotect.acme.corp with return value 12044(A certificate is required to complete client authentication).
Dans ce scénario, l’établissement du tunnel pré-logon a échoué parce que PanGPS n’a pas tenté d’interroger le magasin de certificats de machine provoquant une défaillance préalable à la connexion du portail. Toutefois, le déclencheur est Windows informant PanGPS d’une session utilisateur avant la négociation du tunnel pré-logon est terminée.
Windows peut informer PanGPS de la session utilisateur à différentes étapes de la négociation du tunnel pré-logon, de sorte que les messages d’erreur dans les journaux peuvent varier. La chose la plus importante ici est Windows informant PanGPS au sujet d’une session utilisateur avant l’établissement tunnel pré-logon est terminée et beaucoup avant que l’utilisateur a effectivement entré les informations d’identification pour se connecter à la PC .
Environment
Windows 10 Endpoints utilisant clients GlobalProtect avec la méthode de connexion définie à Pré-Logon.
Cause
Ce problème est causé par une fonctionnalité de Windows, qui peut être appelée « connectez-vous automatique » ou « Logon rapide ». Afin d’accélérer le processus de connexion et de ré-ouvrir les applications qui étaient ouvertes avant un redémarrage, Windows peut être configuré pour utiliser les informations de connexion précédentes pour terminer la configuration de la session utilisateur juste après la fin du processus de redémarrage. Cela est activé par défaut et peut être désactivé en utilisant l’option située à: Paramètres Windows > Comptes > Options de connexion « Utilisez mes informations de connexion pour terminer automatiquement la configuration de mon appareil après une mise à jour ou
redémarrer » Si Windows Automatic Sign-In crée la session utilisateur avant panGPS démarrage, alors nous verrons l’entrée suivante dans le fichier PanGPS.log:
(T2564)Info ( 144): 02/24/21 18:27:37:334 ####################### Start PanGPS service (ver: 5.2.5-66) ####################### (T2564)Info (1517): 02/24/21 18:27:37:334 Enumerate session: user acme\roadrunner logs in on session 1
Cependant, récemment, nous avons observé des scénarios où Windows Automatic Connect-In crée une session utilisateur après le début de PanGPS, ce qui conduit à un comportement erratique pré-logon tunnel. Comme indiqué ci-dessus, Lorsque Windows Automatic Connect-In se produit, PanGPS.log le rend evident , mais le journal de défaillance du tunnel pré-logon n’est pas si ou evident cohérente. En d’autres termes :
- Si Windows Automatic Connect-in informe PanGPS de la session utilisateur avant la négociation du tunnel pré-Logon, alors le tunnel pré-logon échouera ou sera brusquement déconnecté.
- Si Windows Automatic Connect-in informe PanGPS de la session utilisateur après la négociation du tunnel pré-Logon, alors le tunnel pré-logon restera connecté naturellement.
Resolution
Windows Automatic Sign-In ou Fast-Logon doit être désactivé pour que GlobalProtect la fonctionnalité Pré-Logon soit efficace et cohérente.