GlobalProtect-Authentifizierung: Außerkraftsetzung von Cookies und CSC
9965
Created On 04/12/22 15:39 PM - Last Modified 05/13/24 21:52 PM
Symptom
Cookies zur Außerkraftsetzung der Authentifizierung funktionieren möglicherweise nicht, wenn sie in Kombination mit Konfigurationsauswahlkriterien (CSC) verwendet werden, die auf "Geräteprüfungen" und "benutzerdefinierten Prüfungen" basieren.
Environment
- GlobalProtect mit konfigurierten Cookies zur Außerkraftsetzung der Authentifizierung
- Portalkonfiguration mit Config Selection Criteria (CSC ) basierend auf "Device Checks" und "Custom Checks" (nicht bezogen auf die Auswahlkriterien für die Benutzer-/Benutzergruppenkonfiguration)
Cause
Config Selection Criteria (CSC), die auf "Device Checks" und "Custom Checks" basieren, basieren auf dem Sammeln zusätzlicher Informationen vom GP-Client (über getconfig_csc.esp), nachdem der Client authentifiziert wurde, um die richtige Portal Agent-Konfiguration zu erfüllen. Auf der anderen Seite werden die Einstellungen für die Cookie-Behandlung bei der Authentifizierung (Generieren/Akzeptieren) in den Portal Agent-Konfigurationen angegeben. Da die Konfiguration erst nach der Client-Authentifizierung und getconfig_csc Austausch richtig bestimmt wird, können wir nicht sicher sein, ob Cookies akzeptiert werden, bis es zu spät ist (Henne-Ei-Problem).
Dies ist der Grund, warum eine Commit-Warnmeldung hinzugefügt wurde, die besagt:
Authentication Override und Config Selection Criteria -> Device Checks/Custom Checks sind beide konfiguriert. Die Außerkraftsetzung der Authentifizierung wird deaktiviert
Obwohl wir Cookies nicht deaktivieren, kann die Konfiguration je nach dem Rest des Setups wie beabsichtigt funktionieren oder nicht.
Beispiel für einen nicht funktionierenden Fall:
- Die CSC-basierte Konfiguration (oben) akzeptiert Cookies, während die Match-All-Konfiguration unten (nicht CSC-basiert) keine Cookies akzeptiert
- Während des Authentifizierungsprozesses muss Portal (serverseitig) auswerten, ob Cookies zulässig sind, aber es ist unmöglich zu bestimmen, ob die CSC-basierte Konfiguration bis zum Austausch von "getconfig_csc.esp" nach der Authentifizierung abgeglichen wird
- An diesem Punkt findet die Serverseite eine potenzielle Konfigurationsübereinstimmung (die ohne CSC-Kriterien) und verwendet ihre Cookie-bezogenen Einstellungen (in diesem speziellen Beispiel - keine Cookies akzeptieren) und der Benutzer wird gezwungen, sich zu authentifizieren, obwohl sie schließlich mit der CSC-basierten Konfiguration übereinstimmt (nach dem Austausch von "getconfig_csc.esp"), die Cookies zulässt
Der Portalverbindungsprozess läuft wie folgt ab:
- Authentifizierung (Unterscheidung nach Betriebssystem möglich) basierend auf Authentifizierungsprofil und/oder Zertifikatsprofil.
- Cookies können zugelassen/akzeptiert werden, wenn es eine potenzielle Übereinstimmung mit der Konfiguration des Portalagenten gibt, die keine CSC-Prüfungen erfordert, die auch Cookies akzeptiert. Dies würde es ermöglichen, das Cookie zu akzeptieren, bevor die richtige Konfigurationsauswahl "getconfig_csc" wird.
- Hinweis: Unabhängig von der möglichen Konfigurationsübereinstimmung (vor dem CSC-Austausch) und den verwendeten Cookies oder nicht, finden wir am Ende immer die richtige Agentenkonfiguration! Der Benutzer erhält immer die vorgesehene Konfiguration, die "vorab abgeglichene" Konfiguration wird nur auf der Serverseite verwendet, um zu entscheiden, wie mit Cookies während des Authentifizierungsprozesses umgegangen werden soll.
- Nach der Authentifizierung (mit oder ohne Cookies) liefert "getconfig_csc" zusätzliche Details, die erforderlich sind, um die genaue Konfiguration des Portal Agents korrekt abzugleichen.
Resolution
Abhängig von den Client-Konfigurationen, die unter "GlobalProtect Portal Configuration > Agent" aufgeführt sind, kann es sein, dass wir eine erfolgreiche Authentifizierungsüberschreibung mit Konfigurationsauswahlkriterien (CSC) basierend auf "Geräteprüfungen" und "Benutzerdefinierte Prüfungen" konfiguriert haben oder nicht. Szenario 1 : Alle Portal Agent-Konfigurationen akzeptieren Cookies
Dieses
Szenario ist realisierbar. Wir müssen sicherstellen, dass es eine nicht CSC-basierte Portal-Agent-Konfiguration gibt, die Cookies akzeptiert und vor der CSC-Auswertung "vorab abgeglichen" werden kann. Wir können entweder einzelne CSC-basierte Konfigurationen klonen, den CSC-Auswahlteil entfernen und den Klon direkt unter die CSC-basierte Konfiguration legen (was nicht so elegant wäre, wenn es viele Konfigurationen gibt) ODER wir können eine "Catch-All"-Agentenkonfiguration haben, die nicht auf CSC basiert, die die richtigen Einstellungen für die Annahme von Cookies enthält. Diese spezielle Konfiguration sollte in Bezug auf die Funktionen (und/oder zugewiesenen Gateways) eingeschränkt werden, aber der Punkt ist, dass sie für die "endgültige" Konfigurationsübereinstimmung (nach der CSC-Bewertung) überhaupt nicht getroffen werden sollte, sondern nur für die Cookie-Handhabung genutzt werden sollte. Kunden verfügen möglicherweise bereits über nicht-CSC-basierte Konfigurationen mit potenziellen Übereinstimmungen, die die Cookie-Funktionalität zulassen, ohne diese Richtlinie am Ende hinzuzufügen. Szenario 2 : Alle Portal Agent-Konfigurationen akzeptieren KEINE Cookies
Dieses
Szenario ist ebenfalls möglich. Hier gibt es keine besonderen Anweisungen. Cookies sollten in keiner Portal-Agent-Konfiguration aktiviert werden. Szenario 3 : Gemischte Konfigurationsoptionen (einige Agentenkonfigurationen akzeptieren Cookies, andere nicht)
Dieses
Szenario kann erreichbar sein oder auch nicht, je nachdem, was der Endkunde zu erreichen versucht. Der Vorschlag wäre, wenn möglich, einheitliche Cookie-Richtlinien (Szenario 1/2) zu haben.
Der Weg, um einen Teil der gemischten Konfiguration (aus der Cookie-Perspektive) mit CSC zu erreichen, wäre wie folgt (ähnlich wie in Szenario 1):
- Klonen von CSC-basierten Konfigurationen
- Entfernen der geklonten Konfiguration von CSC-basierten Anforderungen ("Device Checks"- und "Custom Checks"-Bedingungen)
- Platzieren Sie sie direkt unter der CSC-basierten Richtlinie, die geklont wurde
Ein weiteres Problem mit dem "geklonten" Konfigurationsansatz besteht darin, dass mehrere CSC-basierte Konfigurationsklone nach dem Entfernen des CSC-Teils möglicherweise gleich aussehen.
Beispiel:
- CSC_A Konfiguration und CSC_B Konfiguration werden ihre jeweiligen nicht-CSC-basierten Klone in der folgenden Reihenfolge erstellt: CSC_A, Non_CSC_A_Clone, CSC_B, Non_CSC_B_Clone.
- Wenn die "Clone"-Konfigurationen identisch sind, würden Non_CSC_B_Clone niemals übereinstimmen, was bedeutet, dass Non_CSC_A_Clone Einstellungen immer verwendet werden (was problematisch ist, falls CSC_A und CSC_B unterschiedliche Cookie-Behandlung benötigen).