Azubi-Projekt: Wie funktioniert das AAA-System?

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.

Traffic Flow
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.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on whatsapp
WhatsApp

Blog-Post teilen

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on whatsapp
WhatsApp

Neueste Beiträge

Das könnte Sie auch interessieren