Citrix nFactor – Authentifizierung neu denken

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

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

Dieser Artikel beschäftigt sich damit, Token–basierte Authentifizierungsprozesse für bestimmte Geräte einfacher zu gestalten. Ganz nach dem Motto: Erhöhung der Usability, ohne die Sicherheit zu verringern. Diese Lösung soll einen Anreiz geben, das Thema Authentifizierung einmal neu zu betrachten.

Das Ziel ist eine Zertifikatsauthentifizierung für unternehmenseigene Geräte. Zugriffe von privaten Geräten sollen weiterhin der RADIUS Authentifizierung unterliegen. 

Anforderungen

Citrix ADC: 

• Firmware: mindestens 11.1 
• Lizenz: Advanced oder Premium 
• Ein konfiguriertes Citrix Gateway mit verbundener Citrix VAAD Umgebung 

Private Key Infrastructure: 

• Unternehmenseigene Geräte müssen mit Benutzerzertifikaten ausgestattet sein 

Erklärungen

Derzeitige Authentifizierungs-Architektur: 

Geplante Authentifizierungs-Architektur:

Im Zielszenario ist das Zertifikat für unternehmenseigene Geräte der erste Faktor und die darauffolgende LDAP-Authentifizierung der zweite. Im Video simuliert das “Canceln” der Zertifikatsabfrage das Fehlen eines Zertifikats.

Ein Überblick über die Komponenten von nFactor ist hier beschrieben: zum Artikel Citrix nFactor – Ablösung Classic Authentication

Im folgenden Verlauf sind die einzelnen Schritte zur Umsetzung beschrieben und durch ADC-CLI-Commands ergänzt.

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 und ein für den AAA vServer erstelltes Zertifikat.

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

Damit der ADC nicht jedes Benutzerzertifikat als gültig ansieht, wird das Root-Zertifikat der ausstellenden Instanz gebunden. Damit lässt der vServer nur Benutzer-Zertifikate zu, die von dieser CA ausgestellt wurden.

bind ssl vserver sec_aaa_vs_nFACTOR -certkeyName ssl_cer_ROOT -CA -ocspCheck Optional

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

Login Schema

In diesem Aufbau verwende ich zwei Authentifizierungs-Zweige. Der erste Zweig authentifiziert den Benutzer über LDAP, wenn das vorhandene Benutzerzertifikat gültig ist. Die Überprüfung auf Benutzerzertifikate wird ohne Login Schema durchgeführt.

Wenn das Zertifikat gültig ist, benötige ich ein Login Schema für die darauffolgende LDAP-Authentifizierung. Ich habe mich an dieser Stelle für ein „only Password“ Login Schema entschieden, da ich den Benutzernamen aus dem Zertifikat auslese. Daher erstelle ich folgendes Schema:

add authentication loginSchema sec_aaa_ls_prof_1Factor -authenticationSchema “/nsconfig/loginschema/OnlyPassword.xml” -userExpression HTTP.REQ.USER.NAME -userCredentialIndex 1 -passwordCredentialIndex 2 -SSOCredentials YES

Für den Zweig „ungültiges Zertifikat“ benötige ich ein Schema, welches die Zwei-Faktor-Authentifizierung übernimmt.

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_CERT_INVALID -rule HTTP.REQ.IS_VALID -action sec_aaa_ls_prof_2Factor

Authentication Policy

Die erste Policy, die ausgeführt wird, ist die Zertifikatsauthentifizierung. Mein Benutzerzertifikat enthält ein Feld Names „SubjectAltName“. Den Inhalt lese ich per Policy aus und benutze diesen als Benutzernamen.

add authentication certAction auth_srv_cert_nFACTOR -twoFactor ON -userNameField SubjectAltName:PrincipalName

add authentication Policy ag_auth_pol_cert_nFACTOR -rule CLIENT.SSL.CLIENT_CERT.IS_VALID -action auth_srv_cert_nFACTOR

Wenn das Zertifikat nicht gültig ist, benötige ich eine Policy für die RADIUS Authentifizierung. Der RADIUS Server besteht laut Anforderung bereits.

add authentication Policy ag_auth_pol_RADIUS -rule true -action ag_auth_srv_RADIUS

Zu guter Letzt benötige ich für beide Wege die LDAP-Authentifizierung, um den Benutzer zu verifizieren. Auch hier verwende ich den bestehenden LDAP Server.

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

Policy Label

Bei beiden Authentifizierungswegen gibt es ein Policy Label. Das erste wird verwendet, um nach erfolgreicher Zertifikatsüberprüfung ein „only Password“ Schema anzuzeigen und den Benutzer mit LDAP zu authentifizieren.

add authentication policylabel sec_aaa_pl_CERT_VALID -loginSchema sec_aaa_ls_prof_1Factor

bind authentication policylabel sec_aaa_pl_CERT_VALID -policyName ag_auth_pol_ldap_nFACTOR -priority 100 -gotoPriorityExpression NEXT

Das zweite Policy Label hat das Login Schema LSCHEMA_INT gebunden, da der RADIUS Token vom Standard Schema übertragen wird. (LSCHEMA_INT = kein Schema)

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

SSL Profil

Die Zertifikatsauthentifizierung ist eine Sonderlocke. Um zu funktionieren nutze ich serverseitige SSL-Renegotiation. Das ermöglicht dem AAA vServer, in einer neu aufgebauten Verbindung zum Client ein Benutzerzertifikat zu verlangen.

add ssl profile ssl_prof_fe_Secure_Renegotiation -eRSA DISABLED -sessReuse ENABLED -sessTimeout 120 -clientAuth ENABLED -clientCert Optional -tls1 DISABLED -tls11 DISABLED -tls13 ENABLED -denySSLReneg FRONTEND_CLIENT -maxage 157680000

bind ssl profile ssl_prof_fe_Secure_Cert -cipherName ssl_cg_fe_Sec -cipherPriority 1

In dem SSL-Profil, welches am Citrix Gateway gebunden ist, aktiviere ich lediglich die Option „Client Authentication“ und stelle es auf optional ein. So kann das Zertifikat über das Gateway an den AAA vServer weitergegeben werden.

Bindings

Nachdem alle nötigen Komponenten erstellt wurden, kann der AAA vServer konfiguriert werden. Das neue SSL-Profil wird gebunden.

set ssl vserver sec_aaa_vs_nFACTOR -sslProfile ssl_prof_fe_Secure_Renegotiation

Das Login Schema für die Zwei-Faktor-Authentifizierung wird gebunden.

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

Mit der höchsten Priorität wird die Policy für die Zertifikatsauthentifizierung hinzugefügt. Als nächster Faktor wird das Policy Label “Cert Valid” angegeben.

bind authentication vserver sec_aaa_vs_nFACTOR -policy ag_auth_pol_cert_nFACTOR -priority 90 -nextFactor sec_aaa_pl_CERT_VALID -gotoPriorityExpression NEXT

Wenn kein Zertifikat zur Überprüfung übermittelt wurde, oder das Zertifikat ungültig ist, übernimmt die nächste Authentifizierungs-Policy. Der zweite Faktor beinhaltet das Policy Label für die RADIUS Authentifizierung.

bind authentication vserver sec_aaa_vs_nFACTOR -policy ag_auth_pol_ldap_nFACTOR -priority 100 -nextFactor sec_aaa_pl_RADIUS_mgmt_verify -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