Ich hatte neulich einen PoC bei einem größeren Kunden, bei dem wir einen Citrix ADC (im HA-Paar) in einer DMZ bereitgestellt haben, um Remote Worker ohne VPN auf die OnPremise-Umgebung mit Citrix Virtual Apps and Desktops zu verbinden. So eine Bereitstellung in einer DMZ kann trotz intensiver Vorbereitung viele Überraschungen mit sich bringen — in den meisten Fällen, weil irgendeine Firewallregel vergessen oder falsch gesetzt wurde. Erstaunt war ich allerdings, dass die kurz darauf folgende Absicherung mit Cisco Duo reibungslos vonstattenging. Zugegeben: Ich war in diesem Fall nur für den Citrix-ADC-Part verantwortlich und musste lediglich einen RADIUS-Server konfigurieren. Neugierig hat mich das aber gemacht, und deswegen habe ich das Ganze im Labor nachgebaut.

Erfreulicherweise stellt Cisco eine 30 Tage Testversion zur Verfügung sowie eine kostenlose Version (für bis zu zehn Benutzer) mit eingeschränktem Funktionsumfang. Nach Ablauf der Testphase in der Vollversion (Beyond) wird euer Account automatisch auf Duo Free umgestellt.

Die Features, die man bereits ab 3 $ im Monat bekommt, sind durchaus interessant — darunter die Möglichkeit, das Token-Gerät (Smartphone) auf Compliance zu prüfen. Für eine 2-Faktor-Authentifizierung mit dem Citrix ADC reicht aber Duo Free. Da ich diesmal für den kompletten Stack verantwortlich war, blieb es nicht bei der Konfiguration des ADC: Neben einem Account bei Cisco Duo wird eine Windows- oder Linux-Maschine mit dem duoauthproxy benötigt, der die Authentifizierungsanfragen Richtung Cisco Cloud weiterleitet. Ich habe mich für eine CentOS-VM entschieden.

Zuerst musste man sich unter https://signup.duo.com einen Account erstellen, was relativ schnell geht. Ich habe das Häkchen bei „Ich bin MSP …“ übrigens nicht gesetzt — und bekam trotzdem eine E-Mail, ob ich nicht Partner von Cisco Duo werden möchte, dass ich dadurch sehr gute Konditionen und weitere kostenlose Accounts bekommen könnte … 🙂

Wenn ihr euren Account erstellt habt meldet ihr euch im Admin Panel an. Dort könnt ihr unter Applications den Citrix NetScaler hinzufügen, indem ihr ihn über den Button „Protect an Application“ sucht.

Achtung: Es gibt auch noch das Citrix Access Gateway. Ich habe Citrix Gateway (NetScaler) ausgewählt, weil die Produktbezeichnung neuer ist — ob es technisch einen Unterschied in der Bereitstellung gibt, weiß ich nicht.

Ihr klickt auf Protect und erhaltet dann in einem neuen Menü die Daten, die ihr später für den duoauthproxy braucht. Notiert sie euch temporär in einem Texteditor eurer Wahl — wir brauchen sie gleich.

Wenn ihr etwas weiter nach unten scrollt, könnt ihr der Applikation einen anderen Namen geben; dieser wird später bei der Anmeldung angezeigt. Darüber hinaus lässt sich hier im 30-tägigen Testzeitraum das Self-Service-Portal konfigurieren — ein Feature, das in der freien Version leider nicht zur Verfügung steht. Wollt ihr später einen Benutzer hinzufügen, müsst ihr das also manuell tun. Zusätzlich lässt sich einstellen, ob alle Schreibweisen eines Benutzernamens gleich behandelt werden sollen. Ich habe das vorerst auf None gelassen und keine Probleme damit festgestellt.

Abschließend scrollen wir nach unten und klicken auf Save.

Wenn ihr noch im Testzeitraum seid, ist im Admin Panel nichts weiter zu tun — wir können den Benutzer später vollautomatisch onboarden. Ist der Testzeitraum abgelaufen und ihr befindet euch in der kostenlosen Version, müsst ihr einen neuen Benutzer manuell anlegen; das passende Menü findet sich unter Users → Add User. Wichtig ist, dass der Benutzername mit dem Namen aus der primären Authentifizierung übereinstimmt, damit ein Match zustande kommt. In den meisten Fällen ist das der UPN (userPrincipalName), der auch der E-Mail-Adresse entspricht.

Damit sind alle wichtigen Schritte im Cisco-Duo-Portal erledigt und wir können uns der OnPremise-Umgebung widmen.

Bereitstellung CentOS mit Duo Authentication Proxy

Bei der Bereitstellung des Proxys habe ich mich weitgehend an die Anleitung von Cisco gehalten. Als Betriebssystem habe ich CentOS gewählt, konkret das Image CentOS-7-x86_64-Minimal-2009.iso. Natürlich könnt ihr auch eine andere Distribution nehmen — unterstützt werden derzeit CentOS, Red Hat Enterprise Linux, Ubuntu und Debian. Alternativ tut es auch ein Windows Server ab 2012. Ich zeige die Installation hier beispielhaft an Linux.

Da der Cisco Duo Authentication Proxy nur als Quellcode vorliegt, müsst ihr zunächst die passenden Developer Tools installieren. Unter CentOS habe ich hierzu folgenden Befehl ausgeführt:

root@linux# yum install gcc make libffi-devel perl zlib-devel diffutils

Nun könnt ihr mit wget den aktuellen Quellcode des Duo Authentication Proxy herunterladen — idealerweise in eurem Home-Verzeichnis:

root@linux# wget --content-disposition https://dl.duosecurity.com/duoauthproxy-latest-src.tgz

Ihr entpackt das Tar-Archiv und wechselt mit cd in den entpackten Ordner. Mit dem Befehl make wird der Quellcode kompiliert.

root@linux# tar xzf duoauthproxy-5.7.3-src.tgz
root@linux# $ cd duoauthproxy-version-src
root@linux# $ make

Nachdem der Quellcode kompiliert wurde — das kann ein paar Minuten dauern — wechselt ihr in den dabei erstellten Ordner und führt das Install-Skript aus:

root@linux# cd duoauthproxy-build
root@linux# ./install

Zunächst müsst ihr den Pfad angeben, in den der Authentication Proxy installiert werden soll. Ich habe den Standard /opt/duoauthproxy belassen und mit Enter bestätigt.

Der Authentication Proxy erstellt bei der Installation einen eigenen Dienstbenutzer. Hier könnt ihr festlegen, wie er heißen soll.

Als Nächstes wählt ihr den Gruppennamen — oder bestätigt den voreingestellten mit Enter.

Jetzt kopiert das Skript die Daten in den Zielordner, erstellt Benutzer und Gruppe und möchte wissen, ob der Authentication Proxy in Zukunft automatisch starten soll. Das solltet ihr mit Yes bestätigen.

Solltet ihr SELinux einsetzen, müsst ihr hier mit Yes noch das entsprechende Modul installieren.

In meinem Fall war kein SELinux installiert. Nach der Installation sollte der Duo Authentication Proxy laufen.

Zusätzlich musste ich die Firewall für den RADIUS-Port öffnen:

 firewall-cmd --zone=public --add-port=1812/udp --permanent

Nun kommen wir zur eigentlichen Konfiguration des Proxys. Dazu öffnen wir mit dem Editor unserer Wahl die Datei /opt/duoauthproxy/conf/authproxy.cfg und richten zunächst den Zugriff auf das Active Directory ein. Wir benötigen dafür: den Hostnamen des DCs, Benutzername und Passwort zum Auslesen des LDAP sowie die Base DN, in der sich die Benutzer befinden.

[ad_client]
host=10.66.255.10
service_account_username=srvadc
service_account_password=Password1!
search_dn=OU=Users,OU=Alpha Corp,DC=itnetx,DC=lab

Im zweiten Abschnitt folgt die Konfiguration des RADIUS-Servers. Der Authentication Proxy unterstützt hier verschiedene Modi. In unserem Fall wird auf dem ADC ein iFrame eingeblendet, über das wir den Login per Push auf dem Smartphone bestätigen. Dazu müsst ihr wissen, welches Template ihr auf dem ADC einsetzt, sonst passt das Layout des iFrames nicht. Hier tragt ihr auch die Daten ein, die ihr beim Anlegen der Applikation erhalten habt, sowie abschließend die IP-Adresse des ADC, das Passwort und den Port.

[radius_server_iframe]
type=citrix_netscaler_rfwebui
api_host=api-XXXXXXXX.duosecurity.com
ikey=DIIIXXXDDDDDDDXXXXX
skey=b3232132132321321321321321321312
failmode=safe
client=ad_client
radius_ip_1=10.66.255.240
radius_secret_1=Password1!
port=1812

Damit der zweite Faktor auch im Citrix Receiver bzw. in der Workspace App funktioniert, brauchen wir einen weiteren Server mit der Konfiguration radius_server_auto. Ansonsten sind die Daten identisch zu oben. Danach speichert ihr die Datei ab; mit systemctl restart duoauthproxy startet ihr den Dienst neu und die Konfiguration wird geladen.

[radius_server_auto]
ikey=DIIIXXXDDDDDDDXXXXX
skey=b3232132132321321321321321321312
api_host=api-XXXXXXXX.duosecurity.com
radius_ip_1=10.66.255.240
radius_secret_1=Password1!
failmode=safe
client=ad_client
port=18120

Konfiguration Citrix ADC

Kommen wir zur Konfiguration des ADC. Ich zeige sie anhand eines ADC Standard mit Advanced Policies, da diese seit Release 13.0-67.x für das Citrix Gateway unterstützt werden. Wir melden uns am NetScaler-Management an.

Wir wechseln zu Citrix Gateway → Virtual Servers, wählen unseren virtuellen Server aus und klicken auf Edit.

Als Nächstes fügen wir den Punkt Authentication Profile hinzu und klicken auf Add, um ein neues Profil zu erstellen.

Nun vergeben wir einen sinnvollen Namen für das Profil und klicken auf Add, um dazu einen Authentication Virtual Server zu erstellen.

Auch hier vergeben wir einen sinnvollen Namen. Die Einstellungen „Non Addressable“ und SSL bleiben, wie sie sind. Mit OK bestätigen wir.

In der Übersicht des Virtual Servers erstellen wir nun eine neue Authentication Policy. Hierzu klicken wir auf „No Authentication Policy“.

Hier klicken wir bei Select Policy auf Add, um eine neue Policy zu erstellen.

Zunächst erstellen wir eine LDAP-Policy, mit der wir das LDAP nach dem Benutzer abfragen. Wir vergeben einen sinnvollen Namen, wählen bei Action Type „LDAP“ und klicken bei Action auf Add, um einen LDAP-Server zu konfigurieren. Als Expression wählen wir true, da die Policy immer greifen soll.

Beim Anlegen des LDAP-Servers benötigen wir im ersten Schritt Servername, Port, Base DN, Administrator Bind DN und Passwort. Die Werte für Base DN und Admin Bind DN lassen sich aus dem Active Directory auslesen. Als Security Type sollte SSL gewählt werden.

Als Server Logon Name Attribute wählen wir New und geben „userPrincipalName“ ein. Wollen wir den Zugriff auf eine bestimmte AD-Gruppe einschränken, müssen wir den Search Filter und das Group Attribute anpassen. Abschließend klicken wir auf OK.

Zurück im Konfigurationsmenü der ersten Authentication Policy sollte unter Action nun der gerade erstellte LDAP-Server ausgewählt sein. Wir klicken auf OK.

Zurück im Policy Binding sollte oben unsere eben erstellte LDAP-Policy stehen. Da wir neben dem ersten Faktor LDAP noch den zweiten Faktor Duo haben, klicken wir bei Select Next Factor auf Add, um einen weiteren anzulegen.

Wir erstellen ein Policy Label, indem wir einen sinnvollen Namen vergeben. Die restlichen Einstellungen lassen wir, wie sie sind, und klicken auf Continue.

Hier klicken wir auf Add Binding, um ein weiteres Policy Binding zu erstellen.

Mit einem Klick auf Add erstellen wir die Policy.

Zunächst vergeben wir wieder einen sinnvollen Namen und wählen als Action Type RADIUS. Die Expression hängt davon ab, ob der Aufruf über den Webbrowser oder die Workspace App erfolgt. Im ersten Schritt legen wir die Policy für den Browserzugriff an, mit folgender Expression:

HTTP.REQ.HEADER("User-Agent").CONTAINS("CitrixReceiver").NOT

Nun klicken wir bei Action auf Add und erstellen den RADIUS-Server.

Hier vergeben wir einen Namen und tragen IP, Port und Secret Key ein. Die Erreichbarkeit des RADIUS-Servers lässt sich direkt testen; nach erfolgreichem Test klicken wir auf Create.

In der Übersicht sollte bei Action nun unser eben erstellter RADIUS-Server stehen. Wir bestätigen die Einstellungen mit OK.

In der Übersicht der Bindings fügen wir mit Add Binding eine weitere Policy hinzu, denn wir brauchen noch eine Bedingung für den Zugriff über Citrix Workspace. Wir legen sie analog zur bestehenden an.

Wichtig ist, dass wir in der Duo-Konfiguration vorher einen separaten Port definiert haben, über den wir den Zugriff der Workspace App regeln. Dazu legen wir mit dem Button Add einen eigenen Server an. Die Expression ist ähnlich der vorherigen:

HTTP.REQ.HEADER("User-Agent").CONTAINS("CitrixReceiver")

Die Konfiguration ist identisch zu vorher, lediglich der Port wurde angepasst.

Nun haben wir zwei Bindings mit zwei verschiedenen Bedingungen als Next Factor angelegt; die Priorität hat der ADC selbst gesetzt. Wir klicken auf Done und anschließend auf Close. In der Übersicht steht jetzt eine Authentication Policy, die wir mit Done bestätigen.

Abschließend bestätigen wir das Authentication Profile auf dem Virtual Server mit OK — damit ist es aktiv.

Wenn ihr alles richtig gemacht habt, begrüßt euch nach dem Login mit Benutzername und Passwort ein Duo-Push-Dialog. Wie er aussieht, hängt davon ab, ob ihr den Benutzer manuell angelegt habt oder die Option „Self-Enrollment“ noch nutzen könnt — denn wie eingangs erwähnt muss der Account in der freien Version im Duo-Portal manuell angelegt werden.

Fazit

Ich hoffe, euch hat die Anleitung gefallen und ihr konntet ihr einigermaßen folgen — ich freue mich immer über konstruktive Kritik. Für mich war die Umsetzung sehr spannend, und ich nutze die Lösung nun seit ein paar Wochen. Ich muss allerdings sagen, dass ich die Azure-SAML-Authentifizierung angenehmer finde, weil ich dort auf SSO-Funktionen zurückgreifen kann, die mir bei Cisco Duo in der freien Version verwehrt bleiben. Trotzdem ist es eine gute Lösung und relativ einfach umzusetzen.