• English
Shop

Citrix ADC – Native OTP als 2FA Lösung

Citrix native OTP– eine Citrix One Time Password – Lösung, ohne einen Drittanbieterserver verwenden zu müssen.

Viele Unternehmen haben bereits die Möglichkeit geschaffen vereinzelt Homeoffice-Arbeitsplätze anzubieten. Dennoch sind die vorhandenen Systeme nicht immer darauf ausgelegt der gesamten Belegschaft gleichzeitig einen Remote-Arbeitsplatz zur Verfügung zu stellen. Oft werden Zwei-Faktor-Lösungen basierend auf Hardwaretoken eingesetzt. Verwaltung und Bereitstellung der Token nehmen viel Zeit und Ressourcen in Anspruch. Die Frage, die dann im Raum steht, ist: “Kann dieser Vorgang schneller und einfacher gestaltet werden?”

Dieser Artikel beschäftigt sich mit dem Szenario, eine bestehende OTP-Lösung durch Citrix native OTP zu ergänzen, und einen Parallelbetrieb sicherzustellen.
Grundlage dafür ist das gängige Beispiel des Zugriffs auf Citrix Virtual Apps and Desktops Ressourcen über Citrix Gateway.

 

Anforderungen

 

Citrix ADC:

 

Active Directory:

  • Attribut (wird verwendet, um das native OTP Secret personenbezogen zu hinterlegen)
    • Typ muss „Directory-String“ sein (Bsp.: UserParameter) 
    • Länge muss mindestens 256 Zeichen betragen
    • String Type muss „Unicode“sein 
  • Service-Benutzer, mit Schreibrechten auf das gewählte Attribut 
  • AD-Gruppe, in der alle Home-Office User ohne Hardware-Token enthalten sind 
  • Synchronisierung aller ADCs und Clients mit einem Zeitserver 

 

Erklärungen

 

Derzeitige Authentifizierungs-Architektur:

Geplante Authentifizierungs-Architektur:

 

Das Verhalten des Login Schemas ändert sich nicht:

 

Umsetzung

 

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 Portal Theme – ein, für den AAA vServer erstelltes Zertifikat und ein SSL Profil:

add authentication vserver sec_aaa_vs_nFACTOR SSL 100.100.100.167 443

bind authentication vserver sec_aaa_vs_nFACTOR -portaltheme RfWebUI_custom

bind ssl vserver sec_aaa_vs_nFACTOR -certkeyName ssl_cer_aaa

set ssl vserver sec_aaa_vs_nFACTOR -sslProfile ssl_prof_fe_Secure

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

 

Login Schema

Bei RADIUS-Lösungen von Drittanbietern wird die Verwaltung der Hardware-Token von diesen Servern übernommen. Im Falle von native OTP muss der ADC dafür sorgen, dass die Informationen ins AD geschrieben werden, und für die Erstellung der OTP-Tokens wieder ausgelesen werden können.

Für die Einrichtung einer Authentication App ist ein Self-Service-Portal erreichbar. Der im Portal hinterlegte Device-Name und das OTP-Secret werden in ein AD-Attribut geschrieben.

 

Beispiel für das Self-Service-Portal: https://citrixGW.company.de/manageotp

 

 

Als Login Schema kann derzeit nur Benutzername/Kennwort verwendet werden. Diese Seite nutzt die gleiche URL wie das Gateway. Deshalb sollte der Zugriff aus dem Internet eingeschränkt oder blockiert werden.

Im folgenden Video habe ich eine Zertifikatsauthentifizierung als ersten Faktor eingerichtet. So können vertrauenswürdige Geräte das Portal aus dem Internet nutzen.

Manage OTP zusätzlich abgesichert durch Benutzerzertifikat:

 

Ein Authentifizierungsprozess mit Zertifikatsvorlage ist hier beschrieben: Citrix nFactor – Authentifizierung neu denken

Eine weitere Methode ist, den Zugriff nur aus bestimmten Subnetzen zuzulassen. Im nachfolgenden CLI-Befehl prüft die Login Schema Policy die URL auf den Pfad „manageotp“ und die Quell-IP-Adresse.

add authentication loginSchema sec_aaa_ls_prof_mgmtOTP –authenticationSchema “/nsconfig/loginschema/LoginSchema/SingleAuthManageOTP.xml” –userCredentialIndex 1 

add authentication loginSchemaPolicy sec_aaa_ls_pol_mgmtOTP –rule “http.REQ.COOKIE.VALUE(\”NSC_TASS\”).EQ(\”manageotp\”) && client.IP.SRC.IN_SUBNET(10.10.10.0/24)” -action sec_aaa_ls_prof_mgmtOTP 

Ich erstelle ein weiteres Login Schema, um in Authentifizierungs-Fällen die Benutzerdaten für die Authentifizierung aufzunehmen. Es handelt sich um ein Benutzername/Kennwort + OTP Token Login Schema.

add authentication loginSchema sec_aaa_ls_prof_2Factor –authenticationSchema “/nsconfig/loginschema/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 Policy

Der erste Zweig des Prozesses enthält die Prüfung, ob die Gateway URL „manageotp“ enthält. Diese Policy sichert das Self-Service-Portal mit einer LDAP Authentifizierung ab.

add authentication Policy ag_auth_pol_ldap_nFactor -rule “http.req.cookie.value(\”NSC_TASS\”).eq(\”manageotp\”) ” -action ag_auth_srv_ldap_upn

Im Self-Service-Portal verwende ich die folgende Policy, um beim Hinzufügen eines neuen Gerätes das OTP-Secret in das AD-Attribut „userParameters“ zu schreiben. Der gebundene Authentifizierungs-Server ist dabei nicht berechtigt eine Authentifizierung durchzuführen. Der Service Benutzer benötigt schreibende Rechte auf das verwendete AD-Attribut.

add authentication ldapAction ag_auth_srv_ldap_otp_mgmt -serverIP 100.100.100.1 -serverPort 636 -ldapBase “DC=wgtieren,DC=dom” -ldapBindDn OTP_svc_ldap@company.de -ldapBindDnPassword 08be117e5ebd6419d80f245asudz223834ee1ba177d53a0fceb896e -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName UserPrincipalName -groupAttrName memberOf -subAttributeName cn -secType SSL -ssoNameAttribute UserPrincipalName –authentication DISABLED -OTPSecret userParameters

add authentication Policy ag_auth_pol_ldap_otp_mgmt -rule “http.req.cookie.value(\”NSC_TASS\”).eq(\”manageotp\”) ” -action ag_auth_srv_ldap_otp_mgmt

Im zweiten Zweig des Prozesses extrahiere ich als erstes die AD-Gruppen des zu authentifizierenden Benutzers. Dazu erstelle ich einen Authentifizierungs-Server, der diese Aufgabe übernimmt und ebenfalls keine Authentifizierung durchführt. Dieser wird an eine neue Policy gebunden.

add authentication ldapAction ag_auth_srv_ldap_upn_NO_auth -serverIP 100.100.100.1 -serverPort 636 -ldapBase “DC=company,DC=de” -ldapBindDn svc_ldap@company.de -ldapBindDnPassword 5ab23484f0245f9d0d9027c9989347f226bcef6a124978f7eab1aa3e867 -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName UserPrincipalName -groupAttrName memberOf -subAttributeName cn -secType SSL -ssoNameAttribute UserPrincipalName –authentication DISABLED

add authentication Policy ag_auth_pol_ldap_otp_NO_auth -rule true -action ag_auth_srv_ldap_upn_NO_auth

Auf Basis der ausgelesenen Benutzergruppen entscheide ich, welche OTP-Lösung genutzt wird.

Die Benutzer, die bereits einen Hardware Token besitzen, benötigen in diesem Zusammenhang keine besondere Behandlung. Ich verwende die Standard-Policies für LDAP und die bestehenden RADIUS-Lösung.

Die Benutzer, die noch nicht für OTP konfiguriert sind, füge ich im Active Directory zu einer gemeinsamen AD-Gruppe „nativeOTP_User“ hinzu. Für diese Mitarbeiter erstelle ich eine LDAP Policy, die auf die Mitgliedschaft in dieser Gruppe prüft.

add authentication Policy ag_auth_pol_ldap_upn_GROUP -rule “AAA.USER.IS_MEMBER_OF(\”nativeOTP_User\”)” -action ag_auth_srv_ldap_upn

Wenn der Benutzer dieser Gruppe zugewiesen ist, wird der Authentifizierungs-Zweig für Citrix native OTP ausgeführt. Es wird eine Policy ausgelöst, die das OTP-Secret aus dem AD-Attribut des Benutzers ausließt. Damit kann der ADC einen OTP-Token berechnen. Derselbe Mechanismus wird in der Authentifizierungs-App des Benutzers ausgeführt. Wenn die erstellten Token übereinstimmen, ist die Authentifizierung über Citrix native OTP erfolgreich.

add authentication ldapAction ag_auth_srv_ldap_otp_auth –serverIP 100.100.100.1 –serverPort 636 –ldapBase “DC=wgtieren,DC=dom” –ldapBindDn svc_ldap@company.de –ldapBindDnPassword 5ab23484f0245f9d0d9027c9989347f226bcef6a124978f7eab1aa3e867 –encrypted –encryptmethod ENCMTHD_3 –ldapLoginName UserPrincipalName –searchFilter “userParameters>=#@” –groupAttrName memberOf –subAttributeName cn –secType SSL –ssoNameAttribute UserPrincipalName -authentication DISABLED –OTPSecret userParameters 

add authentication Policy ag_auth_pol_ldap_otp_auth –rule true -action ag_auth_srv_ldap_otp_auth 

 

Policy Label

Um die vielen „next Factors“ in diesem Prozess abbilden zu können, benötige ich einige Policy Labels. Wieder beginne ich mit dem ersten Prozessbaum, dem Self-Service-Portal. Dieses Label beinhaltet die Policies für das Management und die Authentifizierung über native OTP.

add authentication policylabel sec_aaa_pl_RADIUS_mgmt_verify –loginSchema LSCHEMA_INT 

bind authentication policylabel sec_aaa_pl_RADIUS_mgmt_verify –policyName ag_auth_pol_ldap_otp_mgmt –priority 90 –gotoPriorityExpression NEXT 

bind authentication policylabel sec_aaa_pl_RADIUS_mgmt_verify –policyName ag_auth_pol_ldap_otp_auth –priority 100 –gotoPriorityExpression NEXT 

Nach der erfolgreichen Group Extraction, wird das nächste Policy Label ausgeführt. Es beinhaltet die Policies für die Wege: native OTP und Hardware Token. Dabei hat die Policy, welche auf die Benutzergruppe prüft, eine höhere Priorität.

add authentication policylabel sec_aaa_pl_NEXT_FACTOR –loginSchema LSCHEMA_INT 

bind authentication policylabel sec_aaa_pl_NEXT_FACTOR –policyName ag_auth_pol_ldap_upn_GROUP –priority 100 –gotoPriorityExpression NEXT –nextFactor sec_aaa_pl_RADIUS_mgmt_verify 

bind authentication policylabel sec_aaa_pl_NEXT_FACTOR –policyName ag_auth_pol_ldap_upn –priority 110 –gotoPriorityExpression NEXT –nextFactor sec_aaa_pl_RADIUS 

 

Bindings

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

Dazu binde ich die beiden Login Schemas. Die Schema Policy, mit der höheren Priorität ist die, die auf den Zusatz „manageotp“ in der Gateway URL prüft. Erst danach wird das 2FA Schema gebunden.

bind authentication vserver sec_aaa_vs_nFACTOR –policy sec_aaa_ls_pol_mgmtOTP –priority 90 –gotoPriorityExpression END 

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

 

Ebenfalls mit einer höheren Priorität wird die zum ersten Schema passenden LDAP Policy zum Self-Service-Portal gebunden. Im Anschluss daran soll die Group Extraction Policy ausgeführt werden.

bind authentication vserver sec_aaa_vs_nFACTOR –policy ag_auth_pol_ldap_nFACTOR –priority 90 –nextFactor sec_aaa_pl_RADIUS_mgmt_verify –gotoPriorityExpression NEXT 

bind authentication vserver sec_aaa_vs_nFACTOR –policy ag_auth_pol_ldap_otp_NO_auth –priority 100 –nextFactor sec_aaa_pl_NEXT_FACTOR –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.

 

Um die Ablage des OTP-Secrets im AD sicherer zu gestalten, unterstützen Citrix ADCs ab Version 13.0 eine Verschlüsselung der Informationen.

bind vpn global -userDataEncryptionKey MyCertificate

Außerdem muss die Verschlüsselung in den AAA-Einstellungen aktiviert werden.

Weitere Informationen zur Verschlüsselung von Secrets im Active Directory:

https://docs.citrix.com/en-us/citrix-adc/13/aaa-tm/native-otp-authentication/otp-encrypt-secret.html