Dank Corona sind Zugriffe von extern auf Infrastrukturen gefragter denn je. Der klassische VPN-Weg wird dabei genauso gerne genutzt wie eine Lösung über den Citrix ADC. Deren Vorteil liegt klar auf der Hand: Clientless VPN bzw. die Bereitstellung von Desktops via ICA-Proxy. Oft werde ich gefragt, wie man so eine Lösung neben dem klassischen Konstrukt aus Benutzername und Passwort zusätzlich absichern kann. In meinem letzten Beitrag habe ich die Variante mit Client-Zertifikaten vorgestellt; heute zeige ich euch, wie ihr eine 2-Faktor-Authentifizierung mit Google Authenticator realisiert.

Ich habe diese Anleitung geschrieben, weil es zu diesem Thema zwar sehr viele Dokumentationen gibt, aber selten in Verbindung mit einem Citrix ADC. Wir setzen hier auf ein Ubuntu 20.04 LTS mit FreeRADIUS. Zudem ist das Ubuntu in das Windows-AD aufgenommen, damit wir uns auch lokal mit unseren AD-Daten an der Maschine anmelden können. Die Google-Authenticator-Komponente erzeugt einen QR-Code, den man mit der Google-Authenticator-App auf dem Handy scannen kann. Anschließend erhält man alle 30 Sekunden ein neues Token, das man als zweiten Faktor bei der Anmeldung am Citrix ADC verwenden kann. Neben der hier vorgestellten Variante gibt es auch eine, die direkt im Citrix ADC implementiert ist (Native OTP) — sie setzt allerdings die Advanced oder Premium Edition voraus.

Installation Teil 1 – FreeRADIUS bereitstellen

Eine minimale Standard-Installation von Ubuntu setze ich voraus und beginne direkt mit den Paketen. Nach erfolgreicher Installation unseres Ubuntu 20.04 LTS führen wir zur Sicherheit noch einmal apt update und apt upgrade aus, um etwaige Paketaktualisierungen nachzuholen. Ein OpenSSH-Server sollte idealerweise auch eingerichtet sein, damit sich im späteren Verlauf besser testen lässt. Des Weiteren solltet ihr mit Chrony einen NTP-Client betreiben, damit eure Systemzeit mit der des Domain Controllers übereinstimmt.

Nun starten wir mit der Installation von FreeRADIUS. Dazu führen wir folgenden Befehl aus:

root@ux04:~$ apt install freeradius freeradius-utils

Nach der Installation von FreeRADIUS müssen wir einige Konfigurationen anpassen. Beginnen wir mit der Datei radiusd.conf:

root@ux04:~$ nano /etc/freeradius/3.0/radiusd.conf

Hier müssen wir user und group anpassen: Der Benutzer freerad hat leider nicht das Recht, die Google-Authenticator-Dateien in den einzelnen Benutzerverzeichnissen zu lesen.

Als Nächstes editieren wir die Datei „default“ in der Sites-Konfiguration:

root@ux04:~$ nano /etc/freeradius/3.0/sites-enabled/default

In der Datei müssen wir das pam-Modul aktivieren; hierzu entfernen wir das Kommentarzeichen #.

Nun öffnen wir die Datei users:

root@ux04:~$ nano /etc/freeradius/3.0/users

Hier müssen wir den DEFAULT-Auth-Type auf PAM setzen.

Abschließend legen wir in der clients.conf noch den NetScaler als Authentifizierungsclient an:

root@ux04:~$ nano /etc/freeradius/3.0/clients.conf

Hier muss die NSIP des NetScalers eingetragen werden, dazu ein sicheres Passwort.

Damit ist die Konfiguration von FreeRADIUS abgeschlossen. Als Nächstes kümmern wir uns um den Domain-Join unserer Ubuntu-Maschine. Hierzu installieren wir SSSD:

root@ux04:~$ apt install sssd realmd adcli

Nach der Installation von SSSD könnt ihr direkt den Domain-Join versuchen:

root@ux04:~$ realm join itnetx.lab

Das Ganze ist bei mir allerdings mit einer seltsamen Fehlermeldung fehlgeschlagen.

Ich war mir ziemlich sicher, dass die Pakete installiert sind, und habe kurzerhand Google befragt — es ging offenbar nicht nur mir so. Der Workaround besteht darin, dem Join-Befehl noch ein install-Flag mitzugeben:

root@ux04:~$ realm join itnetx.lab --install=/

Jetzt muss das Administrator-Passwort der Domäne eingegeben werden. Wer einen anderen Benutzer verwenden möchte, gibt dem Join-Befehl den Schalter –user mit.

War der Join erfolgreich, findet ihr jetzt in eurem Active Directory das Computerobjekt.

Zurück auf der Linux-Konsole müssen wir noch eine Anpassung an SSSD vornehmen:

root@ux04:~$ nano /etc/sssd/sssd.conf

Der Punkt access_provider muss auf simple geändert werden.

Als Nächstes passen wir eine Datei unter /etc/pam.d an:

root@ux04:~$ nano /etc/pam.d/common-session

Hier legen wir fest, dass beim Login eines AD-Benutzers ein Home-Verzeichnis angelegt wird. Das brauchen wir, weil der Google Authenticator dort seine Key-Datei ablegt.

Auch die Datei radiusd im Verzeichnis /etc/pam.d muss angepasst werden:

root@ux04:~$ nano /etc/pam.d/radiusd

Das Google-Authenticator-Modul muss hinzugefügt werden, damit es als Authentifizierungsquelle in FreeRADIUS verwendet werden kann.

Abschließend installieren wir noch das Google-Authenticator-Modul für PAM:

root@ux04:~$ apt install libpam-google-authenticator

Nach der Installation des Moduls kann man sich mit einem Domänenbenutzer anmelden und die Token-Generierung starten. Alternativ wechselt man mit su in den Benutzer:

sebastian.busch@itnetx.lab@ux04:~$ google-authenticator

Das Setup ist relativ einfach gehalten, alle Fragen können mit Ja beantwortet werden. Die Einrichtung auf Ubuntu-Seite ist damit beendet — jetzt wechseln wir auf den Citrix ADC.

Installation Teil 2 – Einrichtung des Citrix ADC (NetScaler)

Wir melden uns am Management unseres Citrix ADC an, wechseln in der Navigation auf Citrix Gateway und klicken dort auf Authentication → RADIUS.

Hier können wir neben den Policies auch die zugehörigen Server anlegen — was wir nun tun.

Wir vergeben einen sinnvollen Namen (zum Beispiel den Hostnamen) und tragen dann die IP-Adresse sowie den Port ein, auf dem der FreeRADIUS-Dienst lauscht. Abschließend tragen wir das Passwort ein, das wir zuvor auf Ubuntu-Seite in der clients.conf gesetzt haben.

Solltet ihr nicht sicher sein, ob Port 1812 (der Standard) der richtige ist, könnt ihr auf Ubuntu-Seite prüfen, ob der FreeRADIUS-Dienst überhaupt läuft. Da RADIUS über UDP läuft, brauchen wir dazu folgende Parameter:

root@ux04:~$ netstat -uap

Wenn ihr alle Eingaben vorgenommen habt, könnt ihr mit Test RADIUS Reachability prüfen, ob der Dienst antwortet. Bei einer erfolgreichen Antwort erscheint eine grüne Leiste.

Sollten die passenden RADIUS-Policies noch nicht existieren, müssen wir sie jetzt anlegen. Wir fragen dabei den HTTP-Header ab.

Die eine Bedingung ist erfüllt, wenn der User-Agent im Header CitrixReceiver enthält.

In der zweiten Bedingung darf CitrixReceiver gerade nicht enthalten sein — damit sind alle Browser gemeint.

Ich gehe in meinem Beispiel davon aus, dass ihr bereits einen LDAP-Server zur Authentifizierung am Citrix ADC konfiguriert habt; ich beziehe mich hier also nur auf den zweiten Faktor. Auch bei der LDAP-Konfiguration gibt es Policies (Bedingungen), die sich auf den User-Agent beziehen. Sie werden analog zu den Policies auf RADIUS-Seite angelegt.

Unter Server könnt ihr euren bestehenden LDAP-Server bearbeiten. Wichtig ist der Punkt „Logon Name Attribute“: Dort müsst ihr New auswählen und „userPrincipalName“ eingeben.

Jetzt wird es Zeit, unseren RADIUS-Server als zweiten Faktor an den Virtual Server zu binden. Hierzu klicken wir auf Virtual Servers und wählen unser Citrix Gateway aus.

In der Konfiguration des Virtual Servers müssen wir nun unter Basic Authentication jeweils eine LDAP- und eine RADIUS-Policy hinterlegen.

Dabei ist die Reihenfolge entscheidend: Es macht einen Unterschied, welche Policy an welcher Stelle steht. Warum? Der Citrix Receiver verarbeitet Benutzername, Passwort und Token nicht in derselben Reihenfolge wie ein Login über die Webseite.

Als Erstes legen wir unter Primary die LDAP-Policy „Not Contains Citrix Receiver“ an.

Im nächsten Schritt legen wir unter Primary die RADIUS-Policy „Contains Citrix Receiver“ an.

Nun fügen wir unter Secondary ebenfalls eine LDAP-Policy ein: „Contains Citrix Receiver“.

Danach kommt unter Secondary noch die RADIUS-Policy „Not Contains Citrix Receiver“.

Nachdem die Authentifizierung steht, müssen wir noch Session Policy und Profil anpassen. Wir bearbeiten die Policy, in der die Bedingung auf Contains Citrix Receiver steht.

Den Punkt Credential Index stellen wir auf Secondary um und speichern die Einstellung mit OK. Die Konfiguration ist damit abgeschlossen.

Nun sind wir bereit für den ersten Login.

Wenn alles geklappt hat, können wir unsere Session starten.

Das war die Anleitung zur Bereitstellung einer 2-Faktor-Authentifizierung. Natürlich ist diese Lösung ausbaufähig — vor allem wäre es schön, wenn sich ein Benutzer für die Einrichtung nicht an der Linux-Konsole anmelden müsste. Ein kleines Webformular wäre hier wohl der bessere Weg. Für Fragen, Anregungen und Kritik könnt ihr euch gerne bei mir melden.