Citrix nFactor – Ablösung Classic Authentication am Citrix Gateway

Citrix nFactor bietet eine Möglichkeit, Multi-Step-Authentifizierungen auf Basis verschiedener Techniken/Protokolle abzubilden.

https://support.citrix.com/article/CTX220793

Vor nFactor wurden die Authentifizierungs-Policies an den Citrix Gateway vServer gebunden. Möglich war die Auswahl von Primary und Secondary Policies. In begrenzten Rahmen konnten Szenarien wie Multi-Domänen-Zugriff oder, über Umwege, auch eine Zertifikatsauthentifizierung konfiguriert werden. Doch waren die Möglichkeiten begrenzt.

Dieser Artikel beschäftigt sich mit dem Szenario, die Classic Authentication Policies eines Citrix Gateways abzulösen. Ziel ist es, das Feature nFactor besser zu verstehen und dabei den grundsätzlichen Anmeldeprozess nicht zu verändern.

Anforderungen

Citrix ADC:

• Firmware: mindestens 11.1
• Lizenz: Advanced oder Premium
• Ein konfiguriertes Citrix Gateway mit verbundener Citrix VAAD Umgebung / Das Gateway verlangt eine Zwei-Faktor-Authentifizierung (LDAP + RADIUS)

Erklärungen

AAA vServer

Der AAA vServer übernimmt unter nFactor den Part der Authentifizierung. Das Citrix Gateway leitet die Authentifizierungs-Anfragen an diesen weiter.

Login Schema

Das Login Schema ist die Komponente, die mit dem Benutzer interagiert. Es beschreibt die Anzahl der Eingabefelder und die zu speichernden Informationen. So kann beispielsweise die Eingabe von Benutzername/Kennwort und RADIUS Token zusammen oder getrennt voneinander erfolgen.

Default Authentication Policy

Wie bei Classic Policies besteht die Default Policy aus einem Verbund von Policy und Authentication Server. Ein wichtiger Unterschied zwischen Classic und Default Policies ist der Funktionsumfang der verwendbaren Expressions.

Policy Label

Das Policy Label ist ein Zusammenschluss von Login Schema und Authentication Policy. Diese Komponente kommt zum Einsatz, wenn im ersten Faktor des Prozesses ein Next Factor definiert wird. Im Beispiel der bereits beschriebenen „getrennten Eingabe“ wird ein Standard Login Schema (Benutzername/Kennwort) mit der ersten Authentication Policy verwendet. In der Zuweisung des nächsten Faktors wird ein Policy Label gebunden, welches ein anderes Login Schema mit der Policy des zweiten Faktors verknüpft.

Umsetzung

Um nFactor nutzen zu können, muss das AAA-Feature aktiviert sein.

enable ns feature AAA

AAA vServer

Da ich plane, den vServer auch für Authentifizierungen am Content Switch zu nutzen, erstelle ich einen vServer mit IP-Adresse. Danach binde ich die Komponenten, die bereits auf dem ADC verfügbar sind: Ein SSL-Profil, ein Portal Theme und ein für den AAA vServer erstelltes Zertifikat.

add authentication vserver sec_aaa_vs_nFACTOR SSL 100.100.100.167 443

set ssl vserver sec_aaa_vs_nFACTOR -sslProfile ssl_prof_fe_Secure

bind authentication vserver sec_aaa_vs_nFACTOR -portaltheme RfWebUI_custom

bind ssl vserver sec_aaa_vs_nFACTOR -certkeyName ssl_cer_aaa

• Exkurs: Wenn der AAA vServer nur für die Gateway-Authentifizierung genutzt werden soll, kann dieser „Non Addressable“ sein, da die Authentifizierungs-Anforderung ADC intern weitergeleitet wird. Die Traffic Management vServer führen einen Redirect durch. Dafür muss der AAA vServer vom Client erreichbar sein.

Im Anschluss erstelle ich die neuen Komponenten: Login Schema, Authentifizierungs-Policies und Policy Label.

Login Schema

Das Login Schema soll lediglich den bisherigen Prozess unverändert abbilden, daher behalte ich die Login Page Benutzername/Passwort/OTP Token bei. Das Login Schema besteht aus dem Login Schema Profil und der Login Schema Policy. Dem Profil wird eine .xml-Datei zugewiesen, in der der Seitenaufbau definiert ist. Außerdem kann die Übergabe von Benutzerinformationen konfiguriert werden. Das Profil wird mit der Policy verbunden.

add authentication loginSchema sec_aaa_ls_prof_2Factor -authenticationSchema “/nsconfig/loginschema/DualAuth.xml” -userCredentialIndex 1 -passwordCredentialIndex 2 -SSOCredentials YES

add authentication loginSchemaPolicy sec_aaa_ls_pol_FIRST_FACTOR -rule HTTP.REQ.IS_VALID -action sec_aaa_ls_prof_2Factor

Authentication Policies

Die Policies in diesem Szenario lassen sich leicht in primär und sekundär einteilen, da kein komplexer Prozess geplant ist. Eine Policy ist mit einem Authentication Server verbunden. Diese können aus der bestehenden Konfiguration übernommen werden.

Primärer Faktor:

add authentication Policy ag_auth_pol_ldap_nFACTOR -rule HTTP.REQ.IS_VALID -action ag_auth_srv_ldap_upn

Sekundärer Faktor:

add authentication Policy ag_auth_pol_RADIUS -rule true -action ag_auth_srv_RADIUS

Policy Label

Ein Policy Label ist mit einem Login Schema und einer oder mehreren Authentication Policies verbunden. Mit diesem Verbund wird ein möglicher nächster Faktor abgebildet. Im bestehenden Fall der sekundäre Faktor RADIUS.

add authentication policylabel sec_aaa_pl_RADIUS -loginSchema LSCHEMA_INT

bind authentication policylabel sec_aaa_pl_RADIUS -policyName ag_auth_pol_RADIUS -priority 90 -gotoPriorityExpression NEXT

Bindings

Nachdem alle nötigen Komponenten erstellt wurden, kann der AAA vServer konfiguriert werden.

Dazu werden das erstellte Standard Login Schema…

bind authentication vserver sec_aaa_vs_nFACTOR -policy sec_aaa_ls_pol_FIRST_FACTOR -priority 100 -gotoPriorityExpression END

…und die neu umgesetzten Authentifizierungs-Policies gebunden. Der sekundäre Faktor ist als nextFactor definiert.

bind authentication vserver sec_aaa_vs_nFACTOR -policy ag_auth_pol_ldap_nFACTOR -priority 100 –nextFactor sec_aaa_pl_RADIUS -gotoPriorityExpression NEXT

Damit das Gateway weiß, welcher AAA vServer die Authentifizierung durchführt, wird ein Authentication Profile erstellt…

add authentication authnProfile auth_pro_ext_nFactor -authnVsName sec_aaa_vs_nFACTOR

…und anschließend an den Gateway vServer gebunden.

set vpn vserver nsg_vs_GW_https_443 -authnprofile auth_pro_ext_nFactor

 

Wie ein erweiterter Authentifizierungsprozess aussehen kann, beschreibe ich in meinem nächsten Artikel “Citrix nFactor – Authentifizierung neu denken”.