August 2018
Autor:in des Beitrags
Maximilian
Team Lead Projects – Cloud
Veröffentlicht am
24.08.2018 von Maximilian
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter
Modern Work – digitale Transformation muss ganzheitlich gedacht werden

Weil alles mit allem zusammenhängt

Unsere Auszubildenden bei der Provectus Technologies GmbH erhielten die Aufgabe in unserem Labor eine AAA-Authentifizierung per NetScaler zu einer Webanwendung einzurichten. Wie funktioniert es, wie läuft der Datenfluss ab und was haben sie dabei gelernt? Lesen Sie ihre Erfahrungen in diesem Artikel.

Unter Authentication, Authorization and Auditing (AAA) oder Authentifizierung, Autorisierung und Aufzeichnung, versteht man die Beschreibung eines Systems zur Kontrolle des Zugriffs auf Computerressourcen. Es dient dazu die Identität eines Nutzers festzustellen und ihm gemäß seiner Rechte Zugriff auf für ihn nötige Ressourcen und Services zu gewähren, sowie alle erforderlichen Informationen für Statistiken und die Abrechnung zu sammeln. Im Einzelnen sind dies:
Authentifizierung: Die sichere Identifizierung des Nutzers, mindestens anhand von Namen und Passwort. Es gibt aber weitere und sicherere Möglichkeiten, wie Security-Token oder die Abfrage biometrischer Merkmale, wie Fingerabdruck, Augen Iris oder Gesichtserkennung. Kombiniert man mehrere dieser Möglichkeiten, wie zum Beispiel Passwort und Security-Token, spricht man von einer Multi-Faktor-Authentifizierung.
Autorisierung: Anwendung von Policies, auf welche Ressourcen, Anwendungen und Services der authentifizierte Nutzer zugreifen kann und auf welche nicht.
Aufzeichnung: Auf welche Ressourcen greift der Nutzer zu, inkl. Nutzungsdauer und Menge der Daten, die er nutzt. Die so gewonnen Daten dienen zur Erstellung von Statistiken, zur Planung aktuell und zukünftig benötigter Ressourcen, sowie eventueller Abrechnungszwecke für kostenpflichtige Dienste etc.

Mit dieser Definition, einem recht vereinfachten Ablaufdiagramm und einer kurzen Demonstration unserer wissenden Kollegen bewaffnet, machten wir uns daran den zu erwartenden Traffic-Flow laut der offiziellen Citrix-Doku „How AAA works“ zu erarbeiteten. Dabei stellte sich heraus, dass man dort in zwei Punkten den Application-Server und den Authentication-Server verwechselte, was uns ganz schön aus der Bahn warf und für angeregte Diskussionen sorgte. Denn laut der Doku kontaktet der Client bereits im zweiten Schritt den Application-Server, was unlogisch erscheint, denn zu diesem Zeitpunkt ist der Nutzer noch gar nicht authentifiziert, dürfte also noch gar kein Traffic von ihm bis zum Application-Server durchgehen. Dem ist auch so, wie ein später gezogener Trace bewies. Selbstverständlich fängt der Load-Balancer die erste Anfrage des Client ab und leitet sie zum Authentication-Server weiter. So entstand der folgende von uns erarbeitete Traffic-Flow.

Traffic Flow:

  1. Der Client meldet sich mit der URL zur gewünschten Webanwendung an den Application-Server. Diese landet beim NetScaler Traffic-Management-Virtual-Server, der ihn zum Authentication-vServer umleitet.
  2. Der Authentication-vServer stellt fest, dass der Nutzer noch nicht authentifiziert ist und sendet eine Response via TM vServer zum Client.
  3. Der Client antwortet mit einer Post-Request an den TM vServer.
  4. Der Authentication-vServer erstellt eine Session und setzt ein Cookie mit der ursprünglichen URL des TM vServers. Sodann sendet er eine Response zum TM vServer, welche dieser zum Client weiterleitet.
  5. Der Client antwortet mit einer Get-Request an den TM vServer.
  6. Der TM vServer leitet den Client zur Login-Page auf dem Authentication-vServer.
  7. Der Nutzer gibt seine Credentials ein und sendet eine Post-Request mit den Credentials zurück zur Login-Page.
  8. Sind die eingegebenen Credentials korrekt, wird der Client vom Authentication vServer angemeldet und zur ursprünglichen URL, wie im ursprünglichen Get-Request angegeben, zum Application Server weitergeleitet.

In diesem Flow nicht dargestellt ist die Verwendung eines externen Authentication Servers, was aber durchaus möglich und in der produktiven Praxis üblich ist. In dem Falle findet bei den einzelnen Schritten der Authentifizierung noch eine Kommunikation zwischen dem Authentication-vServer und dem externen Authentication-Server statt, zum Beispiel einem Radius- oder LDAP-Server. In dem hier beschriebenen Fall hingegen kümmert sich der Authentication-vServer um alle Belange der Authentifizierung.
Wie sind wir in der Praxis vorgegangen um AAA in unserer Laborumgebung einzurichten?
Wir erstellten auf dem Citrix NetScaler VPX (1000) unter NetScaler Gateway einen virtuellen Server, gemäß dem Vorbild der bereits vorhandenen, was falsch war. Virtual Server ist eben nicht gleich Virtual Server, da gibt es verschiedene. Jetzt hatten wir zwar einen VPN-Tunnel ins Nirgendwo, aber nicht die gewünschte AAA-Verbindung zu einer Webanwendung. Darum auf Anraten eines kundigen Kollegen den vServer wieder gelöscht und von Vorne angefangen.
Wir erstellten im zweiten Anlauf unter Security -> AAA-Application Traffic einen neuen virtuellen Server. An diesen banden wir das bereits vorhandene Wildcard-Zertifikat, damit eine verschlüsselte Verbindung per SSL bzw. TLS hergestellt werden kann. Als Authentication-Policie verwendeten wir LDAPS. Schlussendlich suchten wir uns im IP-Adressverzeichnis eine freie Adresse und gaben sie dem Server.
Ziel war es die AAA-Authentifizierung gegenüber der Open-Source-Analyseplattform Kibana anzuwenden, die ebenfalls schon existierte. Wir kaperten den bereits vorhandenen Load-Balancer und bogen die Authentication FQDN und den Authentication Virtual Server auf unseren um. Damit der Server im Netz unter dem gewünschten FQDN auch wirklich erreichbar ist, mussten wir nur noch am DNS einen neuen Host (A) mit der richtigen IP-Adresse einrichten. Zwar hätte es auch funktioniert, zumindest auf unserem eigenen Rechner, wenn wir IP-Adresse und FQDN in unsere Hosts-Datei eingetragen hätten, handwerklich sauber aber wäre das nicht gewesen. Der DNS erledigte seinen Job und prompt meldete sich nach Eingabe der von uns vergebenen URL die Login-Page des Authentication-Servers, wohinter Kibana wartete.
Gelernt haben wir dabei, dass wir schon an der Nomenklatur der vorhandenen vServer erkennen hätten müssen, dass wir mit dem virtuellen Gateway-Server auf dem Holzweg waren. Wieder ein Fehler über den man als Azubi stolpert, der glücklicherweise so offensichtlich war, dass man ihn nie wieder vergessen wird. Weswegen man dieses kleine Projekt durchaus als Erfolg bezeichnen kann, denn der gewünschte Lerneffekt trat ein.
Was halten Sie vom Vorgehen unserer Auszubildenden? Haben sie das Gelernte korrekt und verständlich wiedergegeben, oder welche Verbesserungsvorschläge würden Sie ihnen mit auf den Weg geben? Schreiben Sie es uns in die Kommentare.

Das könnte dich auch interessieren

Blogbeitrag

NetScaler Log und Metrik Analytics Server

Wir erklären den Aufbau eines NetScaler Log und Metrik Analytics Server inklusive Monitoring und Alarmierung.
Weiterlesen
Blogbeitrag

Warum der Wechsel zu Citrix NetScaler wieder interessant werden könnte

Wir erklären, Warum der Wechsel zu Citrix NetScaler für Kunden anderer ADC-Anbieter wie F5, AVI Networks oder Kemp Technologies wieder interessant werden könnte.
Weiterlesen
Blogbeitrag

Erneute Lizenzumstellung bei Citrix: Was kommt jetzt auf die Kund*innen zu?

Um die Komplexität des Produktportfolios zu reduzieren, stellt die CSG nun drei neue Abonnementtypen vor.
Weiterlesen
Echt Ich

Echt Ich Matthias

In ECHT ICH erfahrt ihr mehr über Matthias, seinen Arbeitsalltag , seine Hobbys und seine Motivation für einen Job bei Provectus.
Weiterlesen
Blogbeitrag

Passkeys: Die Schlüssel zu einer sichereren und passwortlosen Zukunft

Die Frequenz von Phishing-Attacken steigt immer weiter. Wie sieht also die Authentifizierung der Zukunft aus?
Weiterlesen
Echt Ich

Echt Ich Svenja

In ECHT ICH erfahrt ihr mehr über Svenja, ihren Arbeitsalltag , ihre Rolle im Team und ihre Gründen für einen Job bei Provectus.
Weiterlesen
Blogbeitrag

Entra Private Access – Zero Trust für den hybriden Arbeitsplatz?

Mit Entra Private Access entwickelt Microsoft derzeit die wohl weitsichtigste Lösung für einem Hybriden Arbeitsplatz.
Weiterlesen
Blogbeitrag

Microsoft Copilot

Microsoft läutet mit dem Copiloten eine neue Ära der KI ein. Der Copilot ist mit dem neusten 23H2-Feature-Update für Windows 11 verfügbar und beinhaltet mehr als 150 neue Funktionen.
Weiterlesen
Whitepaper

Lizenzänderungen bei Citrix – Was Sie jetzt wissen müssen

In unserem kostenfreien Whitepaper bringen wir Licht ins Dunkle und erklären Ihnen, was Sie über die aktuelle Situation bei Citrix und die damit einhergehenden Änderungen wissen müssen.
Weiterlesen
Blogbeitrag

Datenschutzkonformer Einsatz von Microsoft 365 bei Sozialdatenträgern

Wir erklären, was Sie beachten sollten, wenn Sie Microsoft 365 als Sozialdatenträger DSGVO-konform einsetzen möchten.
Weiterlesen
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter