text: EPA-Scan als Faktor bei der nFactor-Authentifizierung
  Im Folgenden sind einige der grundlegenden Einheiten von nFactor EPA aufgeführt.
  EPA Action - EPA Action ist ein Aktionstyp, der für nFactor EPA eingeführt wurde. Es enthält Folgendes:
  Client-Sicherheitsausdruck — Dieser Ausdruck wird zur Auswertung an das Gateway-EPA-Plug-in gesendet.
  Erfolgsgruppe — Diese Gruppe wird, falls konfiguriert, an die Gateway-Sitzung geerbt, wenn das EPA-Ergebnis wahr ist.
  Quarantänegruppe — Diese Gruppe wird, falls konfiguriert, an die Gateway-Sitzung geerbt, wenn das EPA-Ergebnis falsch ist.
  KillProcess — Dies stellt den Namen des Prozesses dar, den der EPA-Prozess beenden muss.
  deleteFiles — Gibt kommagetrennte Pfade zu Dateien an, die der EPA-Prozess löschen muss.
  Gruppen können während der Dauer der Sitzung verwendet werden, um festzustellen, ob der Kunde bestimmte EPA-Bedingungen erfüllt. Wenn bei einem bestimmten Faktor die EPA fehlschlägt und die letzte Aktion keine "Quarantänegruppe" enthält, wird die Authentifizierung für diesen Benutzer beendet. Wenn "Quarantänegruppe" existiert, wird die Authentifizierung fortgesetzt und der Administrator kann prüfen, ob die Gruppe eingeschränkten Zugriff gewährt. Weitere Einzelheiten finden Sie unter EPA-Ausführung.
  EPA-Richtlinie - In nFactor werden alle Richtlinien mit derselben Syntax "Authentifizierungsrichtlinie hinzufügen" hinzugefügt. Die Art der Maßnahme qualifiziert die Richtlinie jedoch als EPA-Richtlinie.
  EPA-Faktor - EPA-Faktor ist ein reguläres Policy Label. Es gibt kein Unternehmen, das als EPA-Faktor bezeichnet wird. Sobald die EPA-Richtlinie an einen Faktor gebunden ist, erbt sie bestimmte Eigenschaften, die sie zu einem EPA-Faktor machen. Hinweis: Der Begriff "EPA-Faktor" wird in diesem Dokument üblicherweise verwendet, um sich auf einen Faktor mit EPA-Richtlinien zu beziehen.
  EPA - Quarantäne - Wenn bei einem bestimmten Faktor alle Client-Sicherheitsausdrücke aus allen Aktionen fehlschlagen, und wenn die letzte Aktion "Quarantänegruppe" enthält, wird diese Gruppe zur Sitzung hinzugefügt und der NextFactor wird untersucht. Das heißt, trotz des Scheiterns qualifiziert die Anwesenheit der "Quarantänegruppe" die Sitzung für die nächste Stufe. Aufgrund der Vererbung einer speziellen Gruppe kann der Administrator die Sitzung jedoch auf eingeschränkten Zugriff oder zusätzliche Authentifizierungsrichtlinien wie OTP oder SAML abweisen.
  Wenn bei der letzten Aktion keine Quarantänegruppe vorhanden ist, wird die Authentifizierung bei einem Fehler beendet.
  EPA in nFactor verwendet auch die folgenden Entitäten:
  loginSchema — XML-Darstellung des Anmeldeformulars. Es definiert die "Ansicht" des Anmeldeformulars und hat auch Eigenschaften eines "Faktors".
  Richtlinienbezeichnung oder Richtlinienfaktor — Es handelt sich um eine Sammlung von Richtlinien, die in einer bestimmten Phase der Authentifizierung versucht werden.
  Virtuelles Serverlabel — virtueller Server ist auch ein Policy Label, das heißt, man kann Richtlinien an den virtuellen Server binden. Der virtuelle Server ist jedoch die Sammlung verschiedener Richtlinienbeschriftungen, da er der Einstiegspunkt für den Benutzerzugriff ist.
  nächster Faktor - Er wird verwendet, um das Richtlinienkennzeichnung/den Faktor anzugeben, der nach dem Erfolg der angegebenen Authentifizierungsrichtlinie berücksichtigt werden soll.
  NO_AUTHN policy — spezielle Richtlinie, deren Aktion immer erfolgreich ist.
  Passthrough-Faktor — Ist ein Richtlinienbeschriftung/Faktor, dessen Anmeldeschema keine Ansicht enthält. Dies ist ein Hinweis für die Citrix ADC Appliance, die Authentifizierung mit dem angegebenen Faktor ohne Benutzereingriff fortzusetzen.
  Weitere Informationen finden Sie unter Konzepte, Entitäten und Terminologie von nFactor.
  gegenseitige Exklusivität des EPA-Faktors
  EPA-Faktor enthält eine oder mehrere EPA-Richtlinien. Sobald die EPA-Richtlinien an einen Faktor gebunden sind, sind reguläre Authentifizierungsrichtlinien für diesen Faktor nicht zulässig. Diese Einschränkung soll die beste Benutzererfahrung und eine saubere Trennung der Endpunktanalyse bieten. Die einzige Ausnahme von dieser Regel ist die Richtlinie NO_AUTHN. Da es sich bei der NO_AUTHN-Richtlinie um eine spezielle Richtlinie handelt, die verwendet wird, um "bei einem Ausfallsprung" zu simulieren, ist sie im EPA-Faktor zulässig.
  EPA-Ausführung
  Bei jedem bestimmten Faktor (einschließlich des Faktors für virtuelle Server) prüft die Citrix ADC Appliance vor dem Ausfüllen des Anmeldeformulars, ob der Faktor für EPA konfiguriert ist. Wenn ja, sendet es eine bestimmte Antwort an den Client (UI), sodass die EPA-Sequenz ausgelöst wird. Diese Sequenz umfasst den Client, der nach Sicherheitsausdrücken des Clients fragt und die Ergebnisse sendet. Client-Sicherheitsausdrücke für alle Richtlinien in einem Faktor werden sofort an den Client gesendet. Sobald Ergebnisse auf der Citrix ADC Appliance erhalten wurden, wird jeder der Ausdrücke in allen Aktionen in einer Sequenz ausgewertet. Die erste Aktion, die zu einer erfolgreichen EPA führt, beendet diesen Faktor, und DefaultGroup wird, falls konfiguriert, in die Sitzung vererbt. Wenn eine NO_AUTHN-Richtlinie angetroffen wird, gilt dies als automatischer Erfolg. Wenn der NextFactor angegeben wird, fährt die Appliance mit diesem Faktor fort. Andernfalls endet die Authentifizierung. Diese Bedingung gilt auch für den ersten Faktor. Wenn nach EPA auf dem virtuellen Server kein Authentifizierungsrichtlinienfaktor vorhanden ist, wird die Authentifizierung beendet. Dies unterscheidet sich vom klassischen Richtlinienverhalten, bei dem dem Benutzer immer die Anmeldeseite nach EPA angezeigt wird. Falls jedoch keine erfolgreiche EPA-Richtlinie vorliegt, betrachtet Citrix Gateway die Quarantänegruppe, die für die letzte EPA-Richtlinie in diesem Faktor oder dieser Kaskade konfiguriert wurde. Wenn die letzte Richtlinie mit der Quarantänegruppe konfiguriert ist, wird diese Gruppe zur Sitzung hinzugefügt und der NextFactor wird überprüft. Wenn ein NextFactor existiert, geht die Authentifizierung zu diesem Faktor über. Andernfalls ist die Authentifizierung abgeschlossen.
  Konfigurieren Sie den regelmäßigen EPA-Scan als Faktor bei der nFactor-Authentifizierung
  Sie können den regelmäßigen EPA-Scan mithilfe der erweiterten Richtlinieninfrastruktur als Faktor für die nFactor-Authentifizierung konfigurieren. Hinweis: In der klassischen Richtlinie wurde Periodische EPA als Teil der Sitzungsrichtlinie unter konfiguriert vpn session action. Die folgende Logik wird als Beispiel für die Implementierung des EPA-Scans als Faktor bei der nFactor-Authentifizierung verwendet.
  Der Benutzer versucht, eine Verbindung zu NetScaler Gateway Virtual IP herzustellen.
  Eine Anmeldeseite mit Benutzernamen und Kennwortfeld wird an den Benutzer gerendert, um Anmeldeinformationen anzugeben. Mit diesen Anmeldeinformationen wird eine LDAP- oder AD-basierte Authentifizierung im Back-End durchgeführt. Bei Erfolg wird dem Benutzer ein Popup angezeigt, um den EPA-Scan zu autorisieren.
  Sobald der Benutzer autorisiert hat, wird der EPA-Scan durchgeführt und basierend auf dem Erfolg oder Misserfolg der Benutzerclienteinstellungen wird Zugriff gewährt.
  Wenn der Scan erfolgreich ist, wird der EPA-Scan regelmäßig durchgeführt, um sicherzustellen, dass die konfigurierten Sicherheitsanforderungen weiterhin erfüllt sind.
  Wenn der EPA-Scan bei einer solchen Überprüfung fehlschlägt, wird die Sitzung beendet.
  Es wird davon ausgegangen, dass die folgende Konfiguration vorhanden ist:
  Konfiguration des virtuellen VPN-Servers, des Gateway und der virtuellen Authentifizierungsserver
  LDAP-Serverkonfigurationen und zugehörige Richtlinien.
  Im folgenden Abschnitt werden die erforderlichen Richtlinien und Richtlinienbeschriftungskonfigurationen sowie die Zuordnung von Richtlinien und Richtlinienbezeichnungen zu einem Authentifizierungsprofil beschrieben.
  CLI-Konfiguration der Logik
  Erstellen Sie eine Aktion, um den EPA-Scan durchzuführen, und verknüpfen Sie ihn mit einer EPA-Scanrichtlinie.
  add authentication epaAction EPA-client-scan -csecexpr "sys.client_expr("proc_2_firefox")"
  Der vorhergehende Ausdruck scannt, ob der Prozess 'Firefox' ausgeführt wird. Das EPA-Plug-in prüft alle 2 Minuten die Existenz des Prozesses, was durch die Ziffer '2' im Scan-Ausdruck gekennzeichnet ist.
  Konfigurieren Sie den post-ldap-epa-Richtlinien-Label-Scan`, der die Policy Label für den EPA-Scan hostet.
  Ordnen Sie die in Schritt 1 konfigurierte Policy Label der in Schritt 2 konfigurierten Richtlinienbezeichnung zu.
  Dies vervollständigt den Authentifizierungsmechanismus.
  Konfigurieren Sie ldap-auth policy und verknüpfen Sie es mit einer LDAP-Richtlinie, die für die Authentifizierung bei einem bestimmten LDAP-Server konfiguriert ist.
  Dabei ist ldap_server1 die LDAP-Richtlinie und ldap-auth ist der Richtlinienname.
  Bringen Sie alles zusammen und verbinden Sie ldap-auth policy mit dem virtuellen Citrix ADC AAA-Server, wobei der nächste Schritt auf das Policy Label post-ldap-epa-scan verweist, um einen EPA-Scan durchzuführen.
  Hinweis: In periodischen EPAs, die als mehrere Faktoren konfiguriert sind, wird der neueste Faktor mit periodischer EPA-Konfiguration berücksichtigt.
  Im früheren Beispiel ist EPA der erste Faktor, bei dem der Scan nach dem Prozess "Firefox" sucht.
  Wenn der EPA-Scan erfolgreich ist, führt dies zur LDAP-Authentifizierung, gefolgt vom nächsten EPA-Scan, der nach dem Prozess "Chrome" sucht.
  Wenn mehrere regelmäßige Scans als verschiedene Faktoren konfiguriert sind, hat der neueste Scan Vorrang. In diesem Fall scannt das EPA-Plug-in alle 3 Minuten nach erfolgreicher Anmeldung nach dem Prozess "Chrome".