GlobalProtect Authentification Remplacer les cookies et CSC
9961
Created On 04/12/22 15:39 PM - Last Modified 05/13/24 21:52 PM
Symptom
Les cookies de remplacement d’authentification peuvent ne pas fonctionner lorsqu’ils sont utilisés en combinaison avec des critères de sélection de configuration (CSC) basés sur des « vérifications d’appareil » et des « vérifications personnalisées ».
Environment
- GlobalProtect avec les cookies de remplacement de l’authentification configurés
- Configuration du portail à l’aide des critères de sélection de configuration (CSC) basés sur les « vérifications d’appareil » et les « vérifications personnalisées » (non liées aux critères de sélection de configuration de l’utilisateur/groupe d’utilisateurs)
Cause
Les critères de sélection de configuration (CSC) basés sur les « vérifications d’appareil » et les « vérifications personnalisées » reposent sur la collecte d’informations supplémentaires auprès du client GP (via getconfig_csc.esp) une fois que le client a été authentifié afin de correspondre à la configuration appropriée de l’agent de portail. D’autre part, les paramètres de gestion des cookies de remplacement de l’authentification (Générer/Accepter) sont spécifiés dans les configurations de l’agent du portail. Comme la configuration n’est correctement déterminée qu’après l’authentification du client et l’échange getconfig_csc, nous ne pouvons pas être certains que les cookies sont acceptés avant qu’il ne soit trop tard (problème de type poule et œuf).
C’est la raison pour laquelle un message d’avertissement de validation a été ajouté indiquant :
Remplacement de l’authentification et Critères de sélection de la configuration -> Vérifications de périphériques/Vérifications personnalisées sont toutes deux configurées. Bien
que nous ne désactivions pas les cookies, la configuration peut ou non fonctionner comme prévu en fonction du reste de la configuration.
Exemple qui ne fonctionne pas :
- La configuration basée sur CSC (en haut) accepte les cookies, tandis que la configuration match-all ci-dessous (non basée sur CSC) n’accepte pas les cookies
- Au cours du processus d’authentification, le portail (côté serveur) doit évaluer si les cookies sont autorisés, mais il est impossible de déterminer si la configuration basée sur CSC correspondra avant l’échange « getconfig_csc.esp » qui vient après l’authentification
- À ce stade, le côté serveur trouvera une correspondance de configuration potentielle (celle qui n’a pas de critères CSC) et utilisera ses paramètres liés aux cookies (dans cet exemple particulier - ne pas accepter les cookies) et l’utilisateur sera forcé de s’authentifier, même s’il correspondra éventuellement à la configuration basée sur CSC (après l’échange « getconfig_csc.esp ») qui autorise les cookies
Le processus de connexion au portail se déroule comme suit :
- Authentification (différenciation possible en fonction du système d’exploitation) en fonction du profil d’authentification et/ou du profil de certificat.
- Les cookies peuvent être autorisés/acceptés s’il existe une correspondance potentielle de configuration de l’agent de portail ne nécessitant pas de vérifications CSC qui accepte également les cookies ; Cela permettrait d’accepter le cookie, avant de « getconfig_csc » la sélection de la configuration appropriée.
- Remarque : quelle que soit la correspondance de configuration potentielle (avant l’échange CSC) et les cookies utilisés ou non, nous faisons toujours correspondre la bonne configuration d’agent à la fin ! L’utilisateur recevra toujours la configuration prévue, la configuration « pré-matchée » n’est utilisée que côté serveur pour décider de la façon de gérer les cookies pendant le processus d’authentification.
- Après l’authentification (avec ou sans cookies), « getconfig_csc » fournit les détails supplémentaires nécessaires pour correspondre correctement à la configuration exacte de l’agent du portail.
Resolution
En fonction des configurations client répertoriées sous « GlobalProtect Portal Configuration > Agent », il se peut que nous disposions ou non d’une dérogation d’authentification réussie avec des critères de sélection de configuration (CSC) basés sur les « vérifications de périphérique » et les « vérifications personnalisées » configurées.
Scénario 1 : Toutes les configurations de l’agent du portail acceptent les cookies
Ce scénario est réalisable. Nous devons nous assurer qu’il existe une configuration de l’agent de portail non basée sur le SCC qui accepte les cookies et qui peut être « pré-appariée » avant l’évaluation du CSC. Nous pouvons soit cloner des configurations individuelles basées sur CSC, supprimer la partie sélection CSC et placer le clone juste en dessous de la configuration basée sur CSC (ce qui ne serait pas aussi élégant s’il y a beaucoup de configurations) OU nous pouvons avoir une configuration d’agent « fourre-tout » non basée sur CSC à la fin de la liste, qui contiendrait les paramètres d’acceptation des cookies appropriés ; Cette configuration particulière devrait être limitée en termes de fonctionnalités (et/ou de passerelles attribuées), mais le fait est qu’elle ne devrait pas être affectée du tout pour la correspondance de configuration « finale » (après évaluation CSC), mais plutôt être utilisée uniquement pour la gestion des cookies. Il se peut que les clients disposent déjà de configurations non basées sur CSC avec des correspondances potentielles qui autorisent la fonctionnalité des cookies sans ajouter cette politique en bas.
Scénario 2 : Toutes les configurations de l’agent de portail n’acceptent PAS les cookies
Ce scénario est également réalisable. Il n’y a pas d’instructions particulières ici. Les cookies ne doivent pas être activés dans la configuration de l’agent du portail.
Scénario 3 : Options de configuration mixtes (certaines configurations de l'agent acceptent les cookies, tandis que d'autres ne le sont pas)
Ce scénario peut être réalisable ou non en fonction de ce que le client final essaie d'accomplir ; La suggestion serait d’avoir des politiques cohérentes en matière de cookies (scénario 1/2) si possible.
La façon d’accomplir une partie de la configuration mixte (du point de vue des cookies) avec le SCC impliqué serait la suivante (similaire au scénario 1) :
- Clonage de configurations basées sur CSC
- Suppression de la configuration clonée des exigences basées sur CSC (conditions « Vérifications de l’appareil » et « Vérifications personnalisées »)
- Le placer juste en dessous de la politique basée sur le SCC qui a été clonée
Un autre problème avec l’approche de configuration « clonée » est que plusieurs clones de configuration basés sur CSC peuvent avoir la même apparence après la suppression de la pièce CSC ;
Exemple:
- CSC_A configuration et CSC_B configuration ont leurs clones respectifs non basés sur CSC créés dans l’ordre suivant : CSC_A, Non_CSC_A_Clone, CSC_B Non_CSC_B_Clone.
- Si les configurations « Clone » sont les mêmes, Non_CSC_B_Clone ne correspondraient jamais, ce qui signifie que Non_CSC_A_Clone paramètres seraient toujours utilisés (ce qui est problématique dans le cas où CSC_A et CSC_B besoin d’avoir une gestion différente des cookies).