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

Datenexfiltration in M365 mit Entra ID Conditional Access blockieren

In diesem Artikel taucht unser Experte in die Funktionen aus Conditional Access ein: “app enforced restrictions” und „Conditional Access App Control“ (CAAC).
Weiterlesen
Blogbeitrag

Startschuss für eine neue Geschäftsführung

Wir erweitern die Geschäftsführung und stellen unser neues Führungstrio vor.
Weiterlesen
Echt Ich

Echt Ich Christian

In ECHT ICH erfahrt ihr mehr über Christian, seinen Arbeitsalltag, seine Hobbys und warum er bei Provectus “ECHT ER” sein kann.
Weiterlesen
Blogbeitrag

M365 Compliance Whitepaper

In unserem Whitepaper nehmen wir die Bereiche Datenschutz und Compliance unter die Lupe und geben Ihnen wertvolle Handlungsempfehlungen.
Weiterlesen
Blogbeitrag

Microsoft Power Platform – ja oder nein?

Erfahren Sie, wie Sie die Vorteile und Risiken der Microsoft Power Platform abwägen und die beste Lösung für Ihre Anforderungen finden.
Weiterlesen
Blogbeitrag

M365 Compliance Quick-Assessment

Mit unserem Quick Assessment können Sie einige der typischen Fallstricke zu beleuchten im Themenkomplex „Compliance und Datenschutz und M365″.
Weiterlesen
Blogbeitrag

NetScaler WAF für Citrix Gateway und IP Reputation

Wir zeigen Ihnen zwei Features, die für viele NetScaler Deployments einen Mehrwert hinsichtlich Security bieten.
Weiterlesen
Webinar

Webinar: Neue Lizenzmodelle bei Citrix

Im Webinar informieren Sie unsere Experten über die aktuellen Lizenzänderungen bei Citrix und NetScaler.
Weiterlesen
Whitepaper

Whitepaper – KI-ready

In unserem Whitepaper erhalten Sie einen Überblick über die Herausforderungen, welche die Künstlicher Intelligenz mit sich bringt.
Weiterlesen
Blogbeitrag

Bereitstellung Elastic Stack und Anbindung der NetScaler Syslogs

In diesem Teil steht der Elastic Stack auf dem Plan – Kibana, Elasticsearch und Logstash stehen in den Startlöchern.
Weiterlesen
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter