Ablösung des Forefront Threat Management

Gateways durch Inbetriebnahme

des Citrix Netscalers

Dokumentation zur betrieblichen Projektarbeit

im Rahmen der Abschlussprüfung zur
Fachinformatikerin Systemintegration

Abgabe
Nürnberg, 2. Mai 2017

Auszubildende Ausbildungsbetrieb
Miriam Knichalla Klinikum Nürnberg
Prof.-Ernst-Nathan-Straße 1
Identnummer 90419 Nürnberg
211415
Prüflingsnummer Projektbetreuer
23413 Dipl.-Ing. (FH) Ralph Zederer
 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

Inhaltsverzeichnis
1 Projektumfeld ............................................................................................................................................ 2
1.1 Projektauftrag und Rahmenbedingungen ........................................................................................... 2
1.2 Projektziel ........................................................................................................................................... 2
2 IST-Analyse ............................................................................................................................................... 3
2.1 Grafische Übersicht des IST-Zustandes ............................................................................................ 3
2.2 Ausgangslage ..................................................................................................................................... 3
3 SOLL-Konzept ........................................................................................................................................... 4
3.1 Entwicklung eines Konzeptes ............................................................................................................. 4
3.2 Erstellung eines IP-Adresskonzeptes ................................................................................................. 5
3.3 Grafische Übersicht des SOLL-Konzeptes ......................................................................................... 6
3.4 Schnittstellen und ihre Aufgaben ........................................................................................................ 6
3.5 Ressourcen- und Personalplanung .................................................................................................... 7
3.6 Ablaufplanung ..................................................................................................................................... 7
4 Implementierung des Lösungsansatzes in einer Testumgebung ....................................................... 7
4.1 Vergabe von IP-Adressen und Hostnamen ........................................................................................ 7
4.2 Externer und interner DNS-Eintrag .................................................................................................... 8
4.3 Einstellungen an der Firewall ............................................................................................................. 8
4.4 Notwendige Zertifikate ........................................................................................................................ 9
4.5 Anlegen von AD-Usern und -Gruppen ............................................................................................... 9
4.6 Installation einer Testversion ............................................................................................................ 10
4.7 Durchführung von Funktionstests ..................................................................................................... 10
4.8 Typische Vorgehensweise beim Anlegen von Diensten .................................................................. 10
4.9 Feinkonzeption ................................................................................................................................. 11
4.10 Beschaffung ...................................................................................................................................... 11
5 Umsetzung im Produktivsystem ........................................................................................................... 11
5.1 Vorbereitungen ................................................................................................................................. 11
5.2 Inbetriebnahme der virtuellen Maschine .......................................................................................... 12
5.3 Konfiguration des Citrix Netscalers .................................................................................................. 12
5.3.1 Grundkonfiguration und Sicherheitseinstellungen ....................................................................12
5.3.2 Konfiguration der LDAP-Authentifizierung ................................................................................13
5.3.3 Anbindung des Exchange-Load Balancers ..............................................................................14
5.3.4 Aktivierung von TLS Offloading ................................................................................................14
5.3.5 Filterung der Dienste OWA und ActiveSync .............................................................................14
5.3.6 Weiterleitung von http zu https .................................................................................................15
5.3.7 Abfrage der Zugangsdaten .......................................................................................................16
5.3.8 Implementierung von Single Sign-on .......................................................................................17
5.3.9 Weitere Sicherheitseinstellungen .............................................................................................17
5.4 Überprüfung der Umsetzung des Konzeptes ................................................................................... 17
5.5 Projektübergabe ............................................................................................................................... 18
6 Projektabschluss .................................................................................................................................... 18
6.1 Zeitplan ............................................................................................................................................. 18
6.2 Entstandene Kosten ......................................................................................................................... 19
6.3 Vergleich der Umsetzung mit den Anforderungen ........................................................................... 19
6.4 Ausblick ............................................................................................................................................ 19
6.5 Fazit .................................................................................................................................................. 19
A Anhang .................................................................................................................................................... 20
A1 Glossar ............................................................................................................................................. 20
A2 Abbildungs- und Tabellenverzeichnis ............................................................................................... 21
A3 Quellenverzeichnis ........................................................................................................................... 21

Miriam Knichalla Seite 1 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

Anmerkungen: Begriffe, die kursiv geschrieben sind, wurden im Glossar hinterlegt. Aus Gründen
der Datensicherheit wurden alle Namen und IP-Adressen verfälscht. Die komplette Konfiguration
des Citrix Netscalers wurde von der Autorin ausgeführt und Zuarbeiten von Schnittstellen
entsprechend gekennzeichnet.

1 Projektumfeld
Das Klinikum Nürnberg ist mit 6.100 Mitarbeitern und 2.400 Betten an fünf Standorten im Norden
und im Süden Nürnbergs und im Nürnberger Land eines der größten kommunalen Krankenhäuser
Europas. Im Klinikum werden jährlich 110.000 stationäre und 100.000 ambulante Patienten
behandelt.

Die Abteilung für Informationsverarbeitung ist mit 65 Mitarbeitern und Auszubildenden der interne
IT-Dienstleister des Klinikums Nürnberg. Das Sachgebiet Netz- und Basistechnologien ist für den
Betrieb und die Wartung des Datennetzes zuständig. Neben der Administration wesentlicher
konzernweiter IT-Basis-Dienste – Netzbetrieb und Infrastrukturdienste – fällt der Betrieb der
Exchange-Server und der damit verbundenen Anwendungen Microsoft Office Outlook und
Forefront Threat Management Gateway (TMG) in den Zuständigkeitsbereich des Sachgebietes.
TMG ermöglicht die Bereitstellung des Webmail-Zugriffes auf das Postfach sowie die
Synchronisierung des Postfaches und Kalenders mit mobilen Endgeräten. Aktuell nutzen knapp
200 Beschäftige diesen Service.

1.1 Projektauftrag und Rahmenbedingungen

Als Projektauftrag bekam die Autorin von der Abteilungsleitung die Einführung des Citrix
Netscalers als Nachfolgeprodukt für den abgekündigten TMG übertragen. Bereits im Vorfeld wurde
die Abteilungsleitung von einem externen Dienstleister zur Nachfolgeproduktauswahl beraten. Die
Entscheidung fiel auf den Citrix Netscaler, da dieser sämtliche Funktionalitäten des TMG (siehe
IST-Analyse, Seite 3) bereitstellt und die Möglichkeit offenhält, den externen Zugriff auf die schon
im Haus verwendete Citrix Terminalserverfarm in Zukunft über den Netscaler freizugeben. Dieses
Projekt beschränkt sich auf die Integration des Citrix Netscalers als Nachfolger des TMG.

Vom Auftraggeber wurden folgende Rahmenbedingungen für das Projekt festgelegt:

 Citrix Netscaler als Nachfolgeprodukt
 vorhandene Komponenten und Infrastruktur weiter verwenden
 Lösung als virtuellen Server implementieren
 keine Notwendigkeit für Redundanz
 Projektbudget maximal 6.000 € brutto

1.2 Projektziel
Das Projektziel war die Aufrechterhaltung der Möglichkeit des externen Zugriffs auf die Mitarbeiter-
Postfächer per Open Web Access (OWA) und ActiveSync ohne Auswirkungen auf die Qualität der
Services für den Anwender. Die sichere Bereitstellung der Services mittels TMG konnte durch die
Abkündigung seitens Microsoft nicht mehr gewährleistet werden.

Miriam Knichalla Seite 2 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

2 IST-Analyse
2.1 Grafische Übersicht des IST-Zustandes

Abbildung 1: IST-Zustand mit Forefront TMG

2.2 Ausgangslage
Aktuell werden im Klinikum zwei Exchange-Server mit 6.000 Postfächern und 500 Verteilerlisten in
einem Cluster betrieben. Die Kommunikation zwischen TMG und Postfach-Servern erfolgt über
einen Kemp Load Balancer, der als Hardware-Cluster implementiert ist und die Anfragen verteilt.
TMG wird im Klinikum ausschließlich dazu verwendet, den Zugriff auf die Postfächer des
Exchange-Servers per OWA und ActiveSync zur Verfügung zu stellen. Dadurch haben die
Beschäftigten die Möglichkeit, ihre E-Mails und Kalender auch an Aufenthaltsorten außerhalb des
Klinikums mittels Webbrowser abzurufen oder mit ihren mobilen Endgeräten zu synchronisieren.
Forefront TMG ist im Haus als virtueller Server in einer demilitarisierten Zone (DMZ) implementiert
und publiziert die formularbasierte Anmeldemaske via Internet und Intranet, so dass Mitarbeiter per
TLS gesicherter Verbindung auf ihre E-Mails zugreifen können. Die Kommunikation des TMG aus
der DMZ mit den Backend-Servern im Hausnetz erfolgt ebenfalls per TLS gesicherter Verbindung.
Dazu ist auf dem TMG ein Zertifikat hinterlegt, das auf den Hostnamen bei einer
Zertifizierungsstelle registriert wurde. Die hier verwendete Form der Ende-zu-Ende-
Verschlüsselung ist mit TLS Offloading implementiert. Beim Zugriff auf das Postfach per OWA und
ActiveSync werden vom Benutzer Zugangsdaten – Benutzername und Passwort – eingefordert
und gegen das Active Directory (AD) des Klinikums per LDAP authentifiziert. Dafür werden die AD-
Gruppen „OWA-extern“ und „ActiveSync-extern“ verwendet. TMG authentifiziert sich selbst mit
einem eigenen Benutzerkonto mittels LDAP gegen das AD. TMG verfügt über zwei Netzwerk-
Schnittstellen, wovon eine über eine interne IP-Adresse aus dem DMZ-Netz und die andere über

Miriam Knichalla Seite 3 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

eine externe IP-Adresse aus dem Internet erreichbar ist. Um die Zugriffe auf die öffentliche IP-
Adresse des TMG zu beschränken, ist ein Regelwerk auf der Firewall hinterlegt, das nur http- und
https-Zugriffe zulässt. Aus dem internen Klinikumsnetz sind zusätzlich Zugriffe per SSH und ping
möglich; für Zugriffe von TMG auf das interne Netz sind die Protokolle http, https, LDAP, NTP,
DNS und ICMP freigegeben. Hostnamen und IP-Adressen sind auf den internen sowie externen
DNS-Servern hinterlegt. Es erfolgt täglich eine Sicherung der virtuellen Maschine.

3 SOLL-Konzept
3.1 Entwicklung eines Konzeptes
Eine grundlegende Frage zu Beginn der Konzeptionierung war, ob der Betrieb des Netscalers im
one-arm mode oder im two-arm mode erfolgen sollte. Nach Beratung mit einem externen
Dienstleister fiel der Entschluss, den Netscaler im one-arm mode zu implementieren, da sich im
two-arm mode – in der Standard-Implementierung – eine Netzwerkschnittstelle in der DMZ und die
andere Schnittstelle im Hausnetz befinden würde. Bei einer feindlichen Übernahme des Netscalers
würde der Angreifer so direkt ins interne Klinikumsnetz gelangen. Im one-arm mode muss die
Kommunikation ins Hausnetz noch einmal die Firewall passieren. Eine weitere Variante wäre die
Einrichtung einer zweiten DMZ für den two-arm-mode. Dazu müssten allerdings zusätzliche
Veränderungen an der Infrastruktur vorgenommen werden, was der Rahmenbedingung der
Weiternutzung vorhandener Infrastruktur widerspricht. Für die Implementierung des Netscalers auf
dem ESXi-Server wurden die von Citrix vorgegebenen Minimalanforderungen vorgesehen:

Komponenten Anforderungen
Arbeitsspeicher 2 GB
Virtuelle CPU 2
Virtuelles Netzwerkinterface 1
Speicherplatz 20 GB
Tabelle 1: Anforderungen an den ESXi-Server

Weitere Anforderungen ergaben sich aus der IST-Analyse, da die Implementierung des Netscalers
folgende Funktionalitäten des TMG abdecken sollte:
 Zugriff auf die Postfächer mittels OWA und ActiveSync
 Implementierung in einer DMZ
 Ende-zu-Ende-Verschlüsselung per TLS gesicherter Verbindung
 Authentifizierung und Autorisierung der Benutzer gegen das Active Directory
 Regelwerk zur Beschränkung der Zugriffe auf der Firewall
 regelmäßiges Backup der virtuellen Maschine
Da bisher noch kein Know-how im Umgang mit dem Citrix Netscaler vorhanden war, sollte der
Netscaler in einer Testumgebung erprobt werden. Durch die Teststellung sollte herausgefunden
werden, wo und wie notwendige Einstellungen vorzunehmen sind und welche zusätzlichen
Informationen benötigt werden. Die Testumgebung sollte sich so eng wie möglich an der späteren
Produktivumgebung orientieren und deshalb auf einem ESXi-Server in der DMZ implementiert
werden. Zudem sollten für den Test bereits die IP-Adressen, Firewall-Regeln und AD-Konten
Verwendung finden, die anschließend im Produktivsystem genutzt werden. Der einzige
Unterschied dabei sollte die Nutzung einer kostenlosen Testversion sein.

Miriam Knichalla Seite 4 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

3.2 Erstellung eines IP-Adresskonzeptes

Der Netscaler benötigt zur Inbetriebnahme mindestens drei IP-Adressen:

 Netscaler IP-Address (NSIP): Zugriff auf den Netscaler zu Konfigurations- und Management-
zwecken
 Subnet IP-Address (SNIP): Kommunikation mit den Backend-Servern
 Virtual IP-Address (VIP): Kommunikation mit den Clients

Abbildung 2: Adressbezeichnungen (Quelle: Citrix Netscaler)

Durch die vorbereitende Lektüre der Herstellerdokumentation wurde festgestellt, dass für die
Benutzer-Authentifizierung zwei IP-Adressen, für die LDAP-Abfragen eine IP-Adresse und weitere
IP-Adressen für die zukünftige Bereitstellung zusätzlicher Services über den Netscaler benötigt
werden. Deshalb sollte ein /24 VLAN verwendet werden. Daraus ergab sich folgendes IP-
Adresskonzept (siehe IP-Adressen und Hostnamen, Seite 7):

Adressbereiche Citrix-Bezeichnung Beschreibung

NSIP Management
Management-Bereich
SNIP Backend-Anbindung
Interne Dienste VIP LDAP-Load Balancing
VIP OWA-Gateway
Interne Adressen
VIP Authentifizierung der Anwender
owa.klinikum-nuernberg.de
Öffentliche Adressen
auth.klinikum-nuernberg.de
Tabelle 2: Konzeption der IP-Adressbereiche

Aus dem geplanten Betrieb im one-arm mode resultierte die Notwendigkeit, zwischen den
öffentlichen und internen Adressen NAT einzurichten. Die virtuellen Server für OWA und
ActiveSync sollten über die internen Adressen bereitgestellt und durch DNAT an der Firewall von

Miriam Knichalla Seite 5 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

extern erreichbar gemacht werden. Von außen nicht erreichbar sein sollte die VIP für interne
Dienste, da diese vom Netscaler ausschließlich für AD-Abfragen mittels LDAP genutzt wird.

3.3 Grafische Übersicht des SOLL-Konzeptes

Abbildung 3: SOLL-Konzept: Integration des Citrix Netscalers

3.4 Schnittstellen und ihre Aufgaben

Netzbetrieb: Bereitstellung der IP-Adressen & VLAN
Konfigurationen am DNS-Server
Beauftragung der Eintragung auf den externen DNS-Servern
IT-Security: Implementierung von Firewall-Regeln und DNAT
Bereitstellung der Zertifikate
Systembetrieb: Bereitstellung des ESXi-Servers
Implementierung der virtuellen Maschine & VLAN
Einrichtung des Backups der virtuellen Maschine
PC-Service/Einkauf: Einholen von Angeboten
Beschaffung des Nachfolgeproduktes
Externer Dienstleister: Beratung zur Konfiguration

Miriam Knichalla Seite 6 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

3.5 Ressourcen- und Personalplanung

Als Ressourcen wurden ein ESXi-Server in der DMZ, ein Standard-PC zur Konfiguration sowie ein
Smartphone zum Testen von ActiveSync benötigt. Für die Schnittstellen wurde folgender
Zeitaufwand eingeplant:

Beschreibung Zeitaufwand
Netzbetrieb 1,0 h
IT-Security 1,0 h
Systembetrieb 1,0 h
PC-Service/Einkauf 1,0 h
Externer Dienstleister 2,0 h
Auszubildende 35,0 h
Tabelle 3: Personalplanung

3.6 Ablaufplanung
Für die Aufgaben wurde folgende Ablaufstruktur festgelegt:

Abbildung 4: Projektstrukturplan

4 Implementierung des Lösungsansatzes in einer Testumgebung

4.1 Vergabe von IP-Adressen und Hostnamen
Von der Schnittstelle Netzbetrieb wurde das VLAN 203 vergeben. Es umfasst den Adressbereich
203.0.113.0/24 (siehe SOLL-Konzept, Seite 5).

Miriam Knichalla Seite 7 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

Citrix-
Adressbereiche IP-Adresse Hostname Beschreibung
Bezeichnung
203.0.113.1 netscaler1 NSIP Management-Zugriff
Management
203.0.113.11 snip1 SNIP Backend-Anbindung
Interne Dienste 203.0.113.101 ldap VIP LDAP-Load Balancing

203.0.113.105 exchange VIP OWA-Gateway

Interne
Adressen Authentifizierung der
203.0.113.106 authentication VIP
Anwender
owa.klinikum-
91.213.20.105 exchangeextern
Öffentliche nuernberg.de
Adressen auth.klinikum-
91.213.20.106 authenticationextern
nuernberg.de
Tabelle 4: IP-Adressbereiche

4.2 Externer und interner DNS-Eintrag

Damit die Services von extern erreichbar sind, mussten die öffentlichen Adressen des Netscalers
(91.213.20.105 und 91.213.20.106) mit den dazugehörigen externen DNS-Namen (owa.klinikum-
nuernberg.de und auth.klinikum-nuernberg.de) auf einem externen DNS-Server als A-Record
angelegt werden. Die Schnittstelle Netzbetrieb beauftragte dazu den externen Dienstleister, diese
Einträge vorzunehmen. Für die interne Namensauflösung hinterlegte die Schnittstelle auf den
internen DNS-Servern A-Records für die verwendeten IP-Adressen.

4.3 Einstellungen an der Firewall

Die Schnittstelle IT-Security erstellte an der Firewall folgende Regeln für die Kommunikation mit
dem Backend:

von nach Aktion Protokolle Bemerkungen

Zugriff auf das Management / http
notwendig für Ersteinrichtung (da https-
http, https,
Zugriff erst konfiguriert werden musste)
echo_request,
/ ssh für den Zugriff auf die Konsole /
Admin- echo_reply,
G_Netscaler accept echo_request und echo_reply für die
VLAN 3008, 3010,
Überprüfung der Erreichbarkeit auf den
java, javas,
OSI Layern 1- 3 / https, 3008, 3010,
ssh
java, javas zum Aufrufen der
Weboberfläche
Zugriff über Management- und
Backend-Schnittstelle auf die Zeitserver
und die Domain Controller / ldap für
ldap, ntp, dns, Active Directory-Abfragen / ntp zum
netscaler1, G_Zeitserver,
accept echo_request, Synchronisieren der Zeit / dns für die
snip1 G_DCs
echo_reply Auflösung von Hostnamen zu IP-
Adressen / echo_request und
echo_reply für die Überprüfung der
Erreichbarkeit auf den OSI Layern 1- 3

Miriam Knichalla Seite 8 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

Zugriff über die Backend-Schnittstelle

auf den Exchange-Load Balancer /
https, sicherer https Zugriff auf den Load
Load_Balancer
snip1 accept echo_request, Balancer / echo_request und
_Exchange
echo_reply echo_reply für die Überprüfung der
Erreichbarkeit auf den OSI Layern 1- 3

Tabelle 5: Firewall-Regeln

Für die Kommunikation von externen Clients wurden diese DNAT-Einstellungen vorgenommen:

von nach Protokolle Ziel Bemerkungen

Wird aus dem Internet per http/https
auf „exchangeextern“ (91.213.20.105)
any exchangeextern http, https exchange zugegriffen, wird der Datenverkehr
auf „exchange“ (203.0.113.105)
weitergeleitet.
Wird aus dem Internet per http/https
auf „authenticationextern“
any authenticationextern http, https authentication (91.213.20.106) zugegriffen, wird der
Datenverkehr auf „authentication“
(203.0.113.106) weitergeleitet.
Tabelle 6: DNAT-Regeln

Bei den DNAT-Regeln wurde http zugelassen, da die Anwender bei der Eingabe von URLs in den
Webbrowser häufig vergessen, https einzutragen. Deshalb übernimmt der Netscaler den Redirect
von http zu https (siehe Konfiguration, Seite 15). Durch die DNAT-Einstellungen werden
beispielsweise alle Anfragen für den Zugriff auf das Postfach, die über 91.213.20.105 ankommen,
zu 203.0.113.105 (OWA-Gateway) umgeleitet.

4.4 Notwendige Zertifikate

Um den Zugriff auf die Management-Schnittstelle netscaler1 per https zu ermöglichen, musste die
Schnittstelle IT-Security bei der betriebseigenen CA ein Zertifikat erstellen. Es wurde ein SAN-
Zertifikat gewählt, um sowohl den Hostnamen als auch den FQDN zu hinterlegen.
So wurde ermöglicht, die Management-Weboberfläche über https://netscaler1 oder
https://netscaler1.klinikum-nuernberg.de zu erreichen. Das neu erstellte Zertifikat wurde
anschließend zusammen mit dem Wildcard-Zertifikat für den Zugriff auf OWA und ActiveSync in
die Zertifikatsverwaltung des Netscalers eingespielt.

4.5 Anlegen von AD-Usern und -Gruppen

Damit nur authentifizierte Mitarbeiter OWA und ActiveSync verwenden können, war die
Implementierung der LDAP-Authentifizierung gegen das AD notwendig. Um vom Netscaler aus auf
das AD per LDAP zuzugreifen, musste zunächst im AD das Benutzerkonto „User-Netscaler“ mit
Leserechten angelegt werden. Es wurde ein neues Konto eingerichtet, um es eindeutig einem
Dienst zuordnen zu können. So wird verhindert, dass bei eventuellen Kennwortänderungen ein
anderer Service beeinträchtigt wird. Wichtig bei den Einstellungen war auch, die Option „Kennwort
läuft nicht ab“ zu aktivieren. Durch diese Einstellung wird vermieden, dass die Authentifizierung bei

Miriam Knichalla Seite 9 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

Kennwortablauf nicht mehr funktioniert. Für die Authentifizierung der Anwender werden die bereits
bei TMG verwendeten AD-Gruppen „OWA-extern“ und ActiveSync-extern“ genutzt.

4.6 Installation einer Testversion

Von der Schnittstelle Systembetrieb wurde auf einem ESXi-Server in der DMZ eine virtuelle
Testumgebung bereitgestellt. Eine kostenlose Testversion des Netscalers als OVF-Datei wurde
der Schnittstelle zuvor übergeben. Die Einrichtung des Netscalers erfolgte dann anhand einer
Installationsanleitung, die vom Hersteller zur Verfügung gestellt wurde.
Dies erfolgte in drei Schritten:
1. Als erstes wurde der Zugriff von einem Rechner im Hausnetz per OWA auf das Postfach ohne
die Implementierung von TLS und LDAP realisiert. Dazu musste im Netscaler unterhalb der
Bereiche Load Balancing und Content Switching je ein virtueller Server angelegt werden. Über
den Load Balancing-Server erfolgte die Anbindung an das Backend und über den Content
Switching-Server an das Frontend.
2. Als nächstes musste TLS für die Backend- sowie Frontend-Verbindung eingerichtet werden.
3. Im letzten Schritt wurde die LDAP-Anbindung mit den AD-Konten des TMG umgesetzt.

4.7 Durchführung von Funktionstests

Nach jedem Umsetzungsschritt erfolgten Funktionstests. Dazu wurde von einem Rechner im
Hausnetz die IP-Adresse des virtuellen Servers mit dem Webbrowser aufgerufen. Zunächst
geschah dies über eine ungesicherte http-Verbindung und ohne LDAP-Authentifizierung. Das
Postfach wurde im Browser dargestellt. Nach dem Einspielen der Zertifikate wurde der gesicherte
Aufruf über https getestet und das Postfach über die gesicherte Verbindung dargestellt.
Abschließend erfolgte nach dem Hinterlegen des AD-Benutzerkontos der Test der LDAP-Abfrage.
Nun wurden beim Aufrufen der VIP im Webbrowser die Zugangsdaten abgefragt. Nach
erfolgreicher Anmeldung war der Zugriff auf das Postfach möglich.

4.8 Typische Vorgehensweise beim Anlegen von Diensten

Die Testphase ergab, dass das Verfahren zum Anlegen neuer virtueller Server am Netscaler
immer dreistufig zu erfolgen hat – im Folgenden am Beispiel des LDAP-Load Balancing erläutert.
Die Begrifflichkeiten der jeweiligen Stufen variieren je nach Menüpunkt. Deshalb werden alle im
Netscaler synonym verwendeten Begriffe in eckigen Klammern angeführt.

 Zuerst werden die [Server / Actions / Profile] hinterlegt:

Abbildung 5: Hinterlegte Domain Controller und ihr Status (Screenshot)

 Dann erfolgt die Erstellung von einem/einer [Service / Service-Gruppe / Policy]. Der Service-
Gruppe im Beispiel werden die oben erstellten Server zugewiesen:

Miriam Knichalla Seite 10 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

Abbildung 6: Service-Gruppe für hinterlegte Server (Screenshot)

An dieser Stelle ist es wichtig, ein Monitoring zu hinterlegen. Zur Überprüfung, ob die Domain
Controller der Servicegruppe srvgrp_ldap erreichbar sind, sendet der Netscaler alle 5
Sekunden einen Ping. Nach drei erfolglosen Versuchen wird der Domain Controller, der sich
nicht zurückmeldet, 30 Sekunden auf Down gesetzt, bevor erneut ein Ping gesendet wird.

 Zuletzt wird der/die [Service / Service-Gruppe / Policies] an einen neu zu erstellenden virtuellen
Server gebunden, über den der/die [Service / Service-Gruppe / Policies] erreichbar ist.

Abbildung 7: Virtueller Load Balancing-Server mit Status (Screenshot)

4.9 Feinkonzeption
Die gesammelten Erfahrungen aus der Testphase zeigten, dass die Management-Weboberfläche
standardmäßig nicht per https aufgerufen wird, sondern lediglich per http. Zusätzlich
Berücksichtigung finden sollten die Umstellung des Management-Zugriffs auf https sowie der
personalisierte, authentifizierte Zugriff auf die Management-Weboberfläche und -Konsole. Dazu
sollte eine neue AD-Gruppe für Netscaler-Administratoren genutzt werden.

4.10 Beschaffung
Zur Inbetriebnahme des Netscalers war eine gültige Produktlizenz notwendig. Die Schnittstelle PC-
Service/Einkauf wurde deshalb damit beauftragt, Angebote für die Produktlizenz bei drei externen
Dienstleistern einzuholen. Innerhalb weniger Stunden lagen die Angebote vor. Die Auswahl
erfolgte anhand der Kriterien Preisgestaltung und Serviceleistungen. So fiel die Wahl auf einen
Anbieter mit dem im Sachgebiet Netz- und Basistechnologien bereits sehr gute Erfahrungen im
Hinblick auf Service und Reaktionszeiten bei Supportanfragen gemacht wurden.

5 Umsetzung im Produktivsystem
5.1 Vorbereitungen
Die Grundlage für die Einrichtung der Zugriffsbeschränkung auf die Management-Weboberfläche
und -Konsole erfolgte durch das Anlegen der AD-Gruppe „Gruppe-Admin-Netscaler“. In dieser
Gruppe sind die Mitarbeiter Mitglieder, die als Netscaler-Administrator fungieren. Als Backup
existiert noch das lokale Default-Konto „nsroot“ mit einem mehrstelligen Kennwort, das nur den
Administratoren zugänglich ist.

Die Testversion des Netscalers konnte nicht für die Umsetzung in der Realisierungsphase
verwendet werden, da es sich um die Vorgängerversion des aktuellsten Releases handelte.
Deshalb musste vor Inbetriebnahme der Produktivumgebung sicher gestellt werden, dass es zu
keinem IP-Adresskonflikt mit der Testumgebung kommt. Die virtuelle Maschine der Teststellung
wurde aus diesem Grund unwiederbringlich gelöscht.

Miriam Knichalla Seite 11 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

5.2 Inbetriebnahme der virtuellen Maschine

Der Schnittstelle Systembetrieb wurde eine neue OVF-Datei übergeben. Nach der Installation des
aktuellen Netscaler-Releases auf einem ESXi-Server in der DMZ wurde der virtuellen
Netzwerkschnittstelle die NSIP 203.0.113.1/24 zugewiesen (siehe Tabelle 4, Seite 8). Über diese
IP-Adresse sind die Konfiguration und das Management via Webinterface oder SSH-Protokoll
möglich. Die Erreichbarkeit auf Netzwerkebene wurde nach erfolgreicher Installation mittels des
Konsolenbefehls „ping 203.0.113.1“ von einem Arbeitsplatz-PC getestet. Außerdem erfolgte der
Test der Namensauflösung zusätzlich mit Hilfe des Konsolenbefehls „nslookup netscaler1“ auf
dem Netscaler über die SSH-Schnittstelle. Beide Tests verliefen erfolgreich. Anschließend wurde
die virtuelle Maschine von der Schnittstelle Systembetrieb in die tägliche Sicherungsroutine
aufgenommen.

5.3 Konfiguration des Citrix Netscalers

5.3.1 Grundkonfiguration und Sicherheitseinstellungen

Die komplette Konfiguration erfolgte ab diesem Zeitpunkt über die Weboberfläche. Zuerst mussten
die SNIP 203.0.113.3/24 zur Backendanbindung, der Hostname netscaler1, die IP-Adressen der
drei DNS-Server im Hausnetz sowie die Produktlizenz von Citrix hinterlegt werden. Die Lizenz ist
an Hostname und MAC-Adresse der virtuellen Netzwerkschnittstelle gebunden. Die Funktion des
DNS wurde an dieser Stelle in der Konsole des Netscaler mit „ping google.de“ überprüft.

Abbildung 8: Startkonfiguration (Screenshot)

Anschließend wurden die IP-Adressen der hauseigenen NTP-Server im Netscaler hinterlegt, damit
die Systemzeit des Netscalers synchronisiert wird. Eine falsche Systemzeit kann zu
Sicherheitsproblemen führen. So könnten z.B. bei Störungen die Log-Einträge durch eine falsche
Zeitangabe nicht zugeordnet werden. Die erfolgreiche Synchronisation des Netscalers mit den
Zeitservern wurde in der Konsole mit „show ntp status“ überprüft.

Miriam Knichalla Seite 12 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

5.3.2 Konfiguration der LDAP-Authentifizierung

Als nächstes erfolgte die Einrichtung des Load Balancing für die drei Domain Controller auf denen
das Active Directory läuft (siehe Konfiguration, Seite 10). Dadurch werden die LDAP-Anfragen zur
Authentifizierung gleichmäßig auf die drei Domain Controller verteilt, um bei einem Ausfall von bis
zu zwei Domain Controllern die Anmeldung mit Zugangsdaten weiterhin zu ermöglichen. Für die
Nutzung der LDAP-Authentifizierung, musste ein Authentication LDAP Server (auth_nslb_ldap)
hinterlegt werden, der die Zugangsdaten auf Mitgliedschaft in der AD-Gruppe „Gruppe-Admin-
Netscaler“ abfragt. Außerdem wurde eine Authentication LDAP Policy (pol_nslb_ldap) im Bereich
Sicherheit angelegt, die sämtlichen Traffic zulässt. Bewusst verzichtet wurde an dieser Stelle auf
die Filterung nach erlaubten Subnetzen, da dies bereits vorher von der Firewall übernommen wird
(siehe Firewall-Regeln, Seite 8). Zur Aktivierung der Policy musste diese noch global gebunden
werden, da dies von Citrix für Management-Einstellungen so vorgesehen ist. Nun war die
Anmeldung mit den im AD hinterlegten Zugangsdaten der Administratoren-Gruppe „Gruppe-
Admin-Netscaler“ auf http://netscaler1 möglich.

Abbildung 9: Konfiguration des Zugriffs auf die LDAP-Server (Screenshot)

Beim anschließenden Test verlief die Anmeldung erfolgreich, allerdings war nur die Weboberfläche
des Netscalers ohne Inhalte zu sehen. Um die Inhalte sichtbar zu machen, musste in der User
Administration des Netscalers die AD-Gruppe „Gruppe-Admin-Netscaler“ mit der Berechtigung
„superuser“ für den Vollzugriff hinterlegt werden. Die Default-Einstellung ist hier im
Auslieferungszustand des Netscalers „read-only“ – ohne Berechtigung zum Schreiben und
Einsehen der Konfigurationsdateien.

Nun musste das SAN-Zertifikat noch an den Service für internen Zugriff per https gebunden
werden. Als zu verwendende Protokolle sind hier TLSv1.0, TLSv1.1 und TLSv1.2 erlaubt – auf den
Einsatz von SSL wurde aus Sicherheitsgründen verzichtet. Im Anschluss wurde der http-Zugriff auf
netscaler1 deaktiviert und die sichere Anmeldung mit Administratoren Zugangsdaten auf
https://netscaler1 getestet. Der Test des sicheren Zugriffs auf die Management-Weboberfläche des
Netscalers verlief erfolgreich. Auch der Zugriff per SSH auf die Management-Konsole konnte
erfolgreich getestet werden.

Miriam Knichalla Seite 13 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

5.3.3 Anbindung des Exchange-Load Balancers

Im nächsten Schritt erfolgte die Veröffentlichung des OWA – zunächst noch ohne
Authentifizierung. Dazu mussten, nach dem auf Seite 10 beschriebenen dreistufigen Verfahren, im
Bereich Load Balancing zunächst die IP-Adressen der Exchange-Server hinterlegt werden. Da im
Klinikum den Exchange-Servern ein Hardware-Load Balancer vorgeschaltet ist, wurde die IP-
Adresse des Load Balancers (10.11.12.13) als Server (srv_lbknexch) hinterlegt. Im Folgenden
konnte der Service svc_lbknexch_443 mit TLSv1.0 (TLSv1.1 und TLSv1.2 sind für die Backend-
Kommunikation im Netscaler nicht verfügbar) angelegt werden. Als Monitoring wurde hier ein TCP
Drei-Wege-Handshake eingebunden. Dieser wird vom Netscaler alle fünf Sekunden initiiert und
nach erfolgreichem Ablauf wird die Verbindung zu srv_lbknexch wieder geschlossen. Ist der Ablauf
nicht erfolgreich, wird der hinterlegte Backend-Server auf Down gesetzt.

Im Anschluss wurde noch je ein virtueller Load Balancing-Server für OWA (vsrv_lb_exch_owa) und
ActiveSync (vsrv_lb_exvh_Microsoft-Server-ActiveSync) angelegt und jeweils der Service
lbknexch_443 angebunden, damit per https auf die Exchange-Server zugegriffen werden kann.
Um die Dienste über eine https-Verbindung von extern erreichen zu können, wurde das Wildcard-
Zertifikat, das von einer externen CA authentifiziert wurde, hochgeladen und an die virtuellen
Server für OWA und ActiveSync gebunden. Die Wahl fiel auf ein Wildcard-Zertifikat, da in Zukunft
noch mehr Dienste über den Netscaler angeboten werden sollen. So muss nicht für jeden Dienst
ein eigenes Zertifikat bei einer externen Authentifizierungsstelle angeschafft werden.

5.3.4 Aktivierung von TLS Offloading

Damit die Bedingungen für die Content Switching Policies überprüft und entsprechende Actions –
die Entscheidung zwischen OWA und ActiveSync – angestoßen werden können, musste TLS
Offloading aktiviert werden. Dadurch erhält der Netscaler Zugang zu den Headerinhalten der https-
requests und nimmt zusätzlich die Ver- und Entschlüsselung der Client-Zugriffe vor, um den
Postfach-Servern dadurch Last abzunehmen.

5.3.5 Filterung der Dienste OWA und ActiveSync

Um die Services erreichbar zu machen, musste im nächsten Schritt ein virtueller Content
Switching-Server eingerichtet werden, der die formularbasierte Anmeldemaske von OWA
veröffentlicht. Da nach extern für OWA und ActiveSync nur eine IP-Adresse verwendet wird,
verteilt der virtuelle Content Switching Server die Anfragen nach hinterlegten Policies auf die zuvor
erstellten virtuellen Load Balancing Server. Dazu musste nach dem weiter oben erläuterten
dreistufigen Verfahren (siehe 10) für ActiveSync eine Content Switching Action
(act_cswlbexch_Microsoft-Server-Active-Sync) mit dem Ziel vsrv_lb_exch_Microsoft-Server-
ActiveSync angelegt werden. Diese Action wurde dann an eine Policy (pol_csw_exch_Microsoft-
Server_ActiveSync) gebunden. Die Action wird ausgeführt, wenn die beiden folgenden
Bedingungen der Policy erfüllt sind:
http.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ("owa.klinikum-nuernberg.de") &&
http.REQ.URL.SET_TEXT_MODE(IGNORECASE).STARTSWITH("/Microsoft-Server-ActiveSync")

Bedeutung Zeile 1: Bei dem zu überprüfenden String wird Groß- und Kleinschreibung ignoriert und
wenn der String „owa.klinikum-nuernberg.de“ im http-Request als Hostname enthalten ist, wird der
Boolsche Wert „true“ zurückgegeben. In allen anderen Fällen „false“.

Miriam Knichalla Seite 14 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

Bedeutung Zeile 2: Bei dem zu überprüfenden String wird Groß- und Kleinschreibung ignoriert und
wenn der String "/Microsoft-Server-ActiveSync" in der URL des http-Requests enthalten ist, wird
„true“ zurückgegeben. In allen anderen Fällen „false“.

Anschließend wurde der virtuelle Content Switching-Server (vsrv_csw_exchange) mit der IP-
Adresse 203.0.113.105 angelegt, TLSv1.0, TLSv1.1 und TLSv1.2 aktiviert und die Policy
(pol_csw_exch_Microsoft-Server_ActiveSync) eingebunden.

Für den Zugriff auf OWA mussten weder eine Policy noch eine Action hinterlegt werden, da OWA
die Default-Einstellung ist. Diese wird gewählt, wenn keine Policy, die an den virtuellen Content
Switching-Server (vsrv_csw_exchange ) gebunden ist, zutrifft.

5.3.6 Weiterleitung von http zu https

Damit Aufrufe per http auf https umgeleitet werden, wurde ein weiterer virtueller Content Switching-
Server (vsrv_csw_exchange_http_https_redirect) angelegt, der auf Port 80 lauscht. Dazu musste
eine Responder-Policy (pol_resp_https) angelegt und an den Content Switching-Server gebunden
werden. Die Action der Policy nimmt bei Aufrufen per http einen Redirect auf https vor. Beim
Testaufruf von http://owa.klinikum-nuernberg.de im Webbrowser konnte die erfolgreiche
Weiterleitung auf https beobachtet werden.

Abbildung 10: Kommunikation über den Netscaler

Miriam Knichalla Seite 15 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

5.3.7 Abfrage der Zugangsdaten

Im nächsten Schritt erfolgte die Implementierung der Abfrage der Zugangsdaten für den
autorisierten Zugriff auf OWA und ActiveSync. Dazu musste ein virtueller Server
(vsrv_aaa_auth.klinikum-nuernberg.de) mit der IP-Adresse 213.0.113.106 und dem Wildcard-
Zertifikat im Bereich Security angelegt werden. Ruft der Anwender https://owa.klinikum-
nuernberg.de im Webbrowser auf, wird auf https://auth.klinikum-nuernberg.de weitergeleitet, weil
über diesen virtuellen Server die LDAP-Abfrage gestellt wird. Ist der Anwender Mitglied in der AD-
Gruppe „OWA-extern“, wird nach Eingabe der Zugangsdaten und der erfolgreichen LDAP-Abfrage
von https://auth.klinikum-nuernberg.de wieder zu https://owa.klinikum-nuernberg.de umgeleitet.
Der Anwender kann dann auf sein Postfach zugreifen. Ist die Anmeldung nicht erfolgreich, findet
keine Weiterleitung auf OWA statt.

Damit die Filterung auf berechtigte Mitarbeiter erfolgt, musste im Bereich Security in der
Konfiguration des LDAP-Servers die AD-Gruppe „OWA-extern“ hinterlegt und eine Policy
(pol_nslb_ldap_owa-extern) erstellt werden. Diese Policy wurde an den neu angelegten virtuellen
Authentication-Server (vsrv_aaa_auth.klinikum-nuernberg.de) gebunden und lässt sämtlichen
Traffic zu; die Firewall beschränkt den Traffic bereits auf http- und https-Zugriffe. Dann wurde der
LDAP-Server als Action an die neu erstellte Policy gebunden. Der virtuelle Authentication-Server
musste im Folgenden noch am virtuellen Load Balancing-Server für OWA (vsrv_lb_exch_owa)
zusammen mit der Einstellung „Form Based Authentication“ zur Darstellung eines Eingabefensters
für die Zugangsdaten (siehe Abbildung 9) hinterlegt werden.

Abbildung 11: Formularbasierte Anmeldung (Screenshot)

Nun erfolgte ein Test der vorgenommenen Einstellungen. Dazu wurde im Webbrowser
https://owa.klinikum-nuernberg.de aufgerufen. Es konnte beobachtet werden, wie auf
https://auth.klinikum-nuernberg.de/vpn/tmindex.html weitergeleitet und die formularbasierte
Anmeldemaske im Browserfenster angezeigt wurde. Nach Eingabe von Zugangsdaten aus der

Miriam Knichalla Seite 16 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

AD-Gruppe „OWA-extern“ öffnete sich ein zweites Anmeldefenster, diesmal von den Exchange-
Servern. Nach erneuter Eingabe der Zugangsdaten war der Zugriff auf das Postfach möglich.

Für die Nutzer-Authentifizierung bei ActiveSync waren noch, wie vorher bei der OWA-
Authentifizierung, ein virtueller Server, eine Policy sowie ein LDAP-Server mit der AD-Gruppe
„ActiveSync-extern“ anzulegen. Der virtuelle Server für die ActiveSync-Authentifizierung wurde
anschließend an den virtuellen Load Balancing-Server für ActiveSync (vsrv_lb_exch_Microsoft-
Server-ActiveSync) gebunden. Als Einstellung erfolgte „401 Based Authentication“, da hier keine
Eingabe der Zugangsdaten in eine formularbasierte Anmeldemaske erfolgt. Zum Testen wurde die
Smartphone App Mailwise genutzt. In der App wurde neben der E-Mailadresse und dem Passwort
auch die AD-Kennung eines Mitarbeiters aus der Gruppe „ActiveSync-extern“ sowie der Server
owa.klinikum-nuernberg.de/Microsoft-Server-ActiveSync mit dem Port 443 (https) hinterlegt. Nach
abgeschlossener Kontoeinrichtung synchronisierte sich das Postfach erfolgreich mit Mailwise.

5.3.8 Implementierung von Single Sign-on

Damit sich die Anwender nicht bei jedem Zugriff am Netscaler und am Exchange-Server
authentifizieren müssen, wurde zum Abschluss noch Single Sign-On implementiert. Dazu wurden
im Bereich Security ein Session-Profil (prof_session_sso) und als Single Sign-on Domain
„klinikum-nuernberg.de“ angelegt. Die Option zum automatischen Single Sign-On für alle Web-
Applikationen musste nach erfolgter Authentifizierung am Netscaler aktiviert werden. Damit das
Profil angewendet werden kann, war es auch hier notwendig, eine Policy (pol_session_sso) zu
hinterlegen, die sämtlichen Traffic zulässt, denn die Firewall beschränkt den Traffic bereits auf
http- und https-Zugriffe. Das Profil wurde an die Policy (pol_session_sso) und diese an den
virtuellen Authentication-Server für OWA und ActiveSync gebunden.

5.3.9 Weitere Sicherheitseinstellungen

Zur weiteren Absicherung wurden zum Abschluss eine zusätzliche Action und Policy für HTTP
Strict Transport Security (HSTS) angelegt. Dadurch teilt der Netscaler dem Webbrowser des
Clients über einen zusätzlichen Header mit, dass owa.klinikum-nuernberg.de nach dem ersten
Aufruf für einen bestimmten Zeitraum ausschließlich per https geladen wird. Festgelegt wurde hier
der von Citrix empfohlene Zeitraum von einem halben Jahr. So wird Man-in-the-Middle-Angriffen
vorgebeugt, die den http-request an Port 80 abfangen könnten, um diesen auf eine andere
Webseite umzuleiten. Die Einstellungen zu HSTS wurden im Bereich Rewrite vorgenommen und
die Policy pol_rew_hsts an den virtuellen Content Switching-Server für den Redirect von http zu
https (vsrv_csw_exchenge_http_https_redirect) als Response-Policy gebunden.

5.4 Überprüfung der Umsetzung des Konzeptes

Zur Überprüfung wurde die Debug-Ausgabe auf der Konsole mit folgenden Befehlen gestartet:

Abbildung 12: Konsole mit Anweisung zur Debug-Ausgabe als Text (Screenshot)

Miriam Knichalla Seite 17 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

Im Anschluss wurden auf der Anmeldeseite (https://auth.klinikum-nuernberg.de/vpn/tmindex.html)

gültige Zugangsdaten eingegeben. In der Debug-Ausgabe war erkennbar, dass die Zugangsdaten
akzeptiert wurden. Entsprechend öffnete sich das Postfach im Webbrowser und es konnten E-
Mails gelesen, verfasst und gesendet werden. Bei der Testeingabe von ungültigen Zugangsdaten
wurde im Debug-Fenster ein „reject“ und im Anmeldefenster des Browsers folgender Hinweis
„Ungültige Anmeldeinformationen“ ausgegeben. Dasselbe Verhalten war nach Eingabe gültiger als
auch ungültiger Zugangsdaten in die Smartphone-App Mailwise für ActiveSync zu beobachten.

5.5 Projektübergabe
Da nach Installation des Netscalers alle Funktionstests erfolgreich absolviert wurden, war das
Projekt bereit zur Übergabe an die Abteilungsleitung. Dies erfolgte per E-Mail mit dem Hinweis auf
die neue URL https://owa.klinikum-nuernberg.de und der Bitte, die Anmeldung auszuprobieren.
Nach erfolgter Abnahme durch die Abteilungsleitung wurden die Mitarbeiter, die zur Nutzung von
OWA und ActiveSync berechtigt sind, per E-Mail informiert, dass die URL sowie die Gestaltung der
OWA-Anmeldeseite geändert wurden.

6 Projektabschluss
6.1 Zeitplan
Geplante Tatsächliche
Projektphase Differenz
Dauer Dauer
Aufnahme und Dokumentation des IST-Zustandes 2,0 h 2,0 h
Erstellung eines SOLL-Konzeptes 3,0 h 3,0 h
Implementierung des Lösungsansatzes in einer
10,0 h 11,5 h +1,5 h
Testumgebung
Planung und Umsetzung des Konzeptes im
9,0 h 8,0 h -1,0 h
Produktivsystem
Test und Übergabe 6,0 h 5,5 h -0,5 h
Dokumentation 5,0 h 5,0 h
Gesamtdauer 35,0 h 35,0 h +/- 0 h
Tabelle 7: Projektzeitplanvergleich

Die Abweichungen der kalkulierten von der tatsächlichen Zeit begründen sich wie folgt:
 Durch den großen Funktionsumfang des Netscalers musste zuerst ein Überblick über die
Organisation des Menüs mit seinen umfangreichen Unterpunkten erlangt werden. Da laut den
Anleitungen von Citrix Anforderungen und Einstellungen an mehreren Stellen umgesetzt und
vorgenommen werden können, musste zunächst ausprobiert werden, welche Einstellungen für
dieses Projekt am effektivsten sind. Dies nahm mehr Zeit in Anspruch als eingeplant.

 Durch die intensive Einarbeitung und die gesammelten Erfahrungen während der
Testimplementierung wurde ein gezielter Zugriff auf die notwendigen Einstellungen bei der
Umsetzung des Produktivsystems möglich. Dadurch konnte eine Stunde eingespart werden.
Während der Test- und Übergabephase wurde eine weitere halbe Stunde eingespart, da alle
Tests weitgehend fehlerfrei verliefen und die Beteiligten motiviert mitarbeiteten.

Miriam Knichalla Seite 18 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

6.2 Entstandene Kosten

Die Kosten für das Projekt ergeben sich aus den Produktlizenzkosten des Citrix Netscalers und
den Personalkosten. Da das Projekt im laufenden Betrieb durchgeführt wurde, mussten die
Personalkosten für die Leistungen der einzelnen Schnittstellen nicht im Rahmen dieses
Projektbudgets erfasst werden. Die für das Projekt eingesetzte Arbeitszeit der Autorin belief sich
auf 35 h. Die Arbeitsstunde einer Auszubildenden wird im Klinikum mit 18,50 € verrechnet – das
sind in Summe 647,50 € brutto. Die Kosten für die Produktlizenz und die angefallenen
Beratungskosten des externen Dienstleisters belaufen sich auf eine Höhe von 4.376,46 € brutto.
Darüber hinaus entstanden keine weiteren Kosten, da vorhandene Komponenten und Infrastruktur
genutzt wurden. Die Gesamtkosten für das Projekt belaufen sich also auf 5.023,96 € brutto.

6.3 Vergleich der Umsetzung mit den Anforderungen

Die Anforderungen aus dem SOLL-Konzept wurden in der Umsetzung des Projektes vollständig
erfüllt. Die vom Auftraggeber vorgegebenen Rahmenbedingungen wurden komplett eingehalten.
Das maximale Projektbudget wurde um fast 1.000 € unterschritten.

Rahmenbedingungen erfüllt
Citrix Netscaler als Nachfolgeprodukt

Nutzung vorhandener Komponenten und Infrastruktur

Umsetzung als virtueller Server

Keine Redundanz

Kosten von maximal 6.000 € brutto

Tabelle 8: Vergleich der Umsetzung mit den Rahmenbedingungen

6.4 Ausblick
Es ist angedacht, in naher Zukunft den Zugriff auf die hauseigene Citrix-Terminalserverfarm über
das Netscaler Gateway mittels Zwei-Faktor-Authentifizierung zu ermöglichen. Im Moment erfolgt
der Zugriff über ein IPSec-VPN; dies setzt eine etwas aufwendigere Konfiguration für jede
Verbindung voraus.

6.5 Fazit
Mein persönliches Fazit: das Projekt kann als sehr gelungen gewertet werden, da das anvisierte
Projektziel vollständig erreicht wurde. Das Feedback nach der Übergabe fiel allgemein sehr positiv
aus. Mir hat gefallen, dass ich selbständig und eigenverantwortlich ein Projekt durchführen und
erfolgreich zum Abschluss bringen konnte. Darüber hinaus habe ich meine Fachkenntnisse in
verschiedenen Bereichen (z.B. Firewall, TLS) erweitert. Dies wird mir in Zukunft in meiner
täglichen Arbeit weiterhelfen.

Miriam Knichalla Seite 19 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

A Anhang
A1 Glossar
Verzeichnisdienst mit Rechteverwaltung, der ein Netzwerk z.B.
Active Directory entsprechend der realen Struktur des Unternehmens gliedert, Objekte wie
Computer, Benutzer, Gruppen verwaltet und Zugriffe beschränkt
Software, die die Datensynchronisation und den Zugriff von einem mobilen
ActiveSync
Endgerät auf das Postfach eines Exchange-Servers ermöglicht
Variable, die nur zwei Werte (wahr oder falsch) annehmen kann und als
Boolscher Wert
Bedingung für Abfragen genutzt wird
CA certification authority – eine Instanz, die digitale Zertifikate ausstellt
Hardwareverbund zur Steigerung der Verfügbarkeit der darauf laufenden
Cluster
Dienste und zur höheren Ausfallsicherheit
demilitarisierte Zone – Netzwerkbereich zwischen der Internet-Firewall und
DMZ
der internen Firewall, der von außen erreichbar ist
Destination-NAT, (siehe NAT) – unterschiedliche Dienste werden unter
DNAT einer einzigen Ziel-IP-Adresse angeboten und die Adressinformationen an
der Ziel-Firewall ersetzt
domain name system – Umsetzung des Hostnamens in die dazugehörige
DNS
IP-Adresse und umgekehrt
Hostsystem von VMware, das den simultanen Betrieb mehrerer virtueller
ESXi
Gastsysteme erlaubt
full qualified domain name – eindeutiger Name eines Internet-Hosts, der
FQDN sich aus dem Hostnamen und dem Namen der Domain zusammensetzt
(z.B. owa.klinikum-nuernberg.de)
http strict transport security – Sicherheitsmechanismus für https-
HSTS
Verbindungen
internet control message protocol – dient in Netzwerken dem Test der
ICMP
Erreichbarkeit und zur Fehlerermittlung
lightweight directory access protocol – zur Abfrage und Änderung von
LDAP
Informationen von Verzeichnisdiensten (siehe Active Directory)
Load Balancer verteilt die Last der Anfragen auf die Rechner in einem Cluster
Angriffsform, bei der der Angreifer den Netzwerkstrom aufbricht, um die
Man-in-the-Middle
Kommunikation mitzulesen und zu manipulieren
network address translation – ersetzt automatisiert Adressinformationen in
NAT
Datenpaketen durch andere Adressinformationen
NTP network time protocol – Standard zur Synchronisierung von Uhrenzeiten
one-arm mode Modus, der nur eine Netzwerkschnittstelle benötigt
open virtualization format – offenes Virtualisierungsformat zum Verpacken
OVF
und Verteilen von virtuellen Maschinen
open web app / access – ermöglicht den Zugriff auf E-Mail- Postfächer über
OWA
das Internet und Intranet
Postfach-Server Rolle des Exchange-Servers, zuständig für die Bereitstellung der Postfächer
bezeichnet das zusätzliche Vorhandensein funktional gleicher oder
Redundanz
vergleichbarer Ressourcen zur Datensicherheit
subject alternative name – Zertifikat in das mehrere DNS-Namen einer
SAN-Zertifikat
Domäne hinterlegt werden können
secure shell – Netzwerkprotokoll zum Aufbau einer verschlüsselten
SSH
Verbindung
TLS Offloading transport layer security offloading – TLS Verschlüsselung und

Miriam Knichalla Seite 20 von 21

 Ablösung des Forefront Threat Management Gateways durch Inbetriebnahme des Citrix Netscalers

-Entschlüsselung werden vom Web-/Exchange-Server auf separaten Server

ausgelagert
transport layer security – hybrides Verschlüsselungsprotokoll zur sicheren
TLS
Datenübertragung
virtual local area network – logisches Teilnetz innerhalb eines
VLAN
physikalischen Netzes
Tabelle 9: Glossar

A2 Abbildungs- und Tabellenverzeichnis

Abbildung 1: IST-Zustand mit Forefront TMG ..................................................................................3
Abbildung 2: Adressbezeichnungen (Quelle: Citrix Netscaler) .........................................................5
Abbildung 3: SOLL-Konzept: Integration des Citrix Netscalers ........................................................6
Abbildung 4: Projektstrukturplan ......................................................................................................7
Abbildung 5: Hinterlegte Domain Controller und ihr Status (Screenshot) .......................................10
Abbildung 6: Service-Gruppe für hinterlegte Server (Screenshot) .................................................11
Abbildung 7: Virtueller Load Balancing-Server mit Status (Screenshot) .........................................11
Abbildung 8: Startkonfiguration (Screenshot) ................................................................................12
Abbildung 9: Konfiguration des Zugriffs auf die LDAP-Server (Screenshot)...................................13
Abbildung 10: Kommunikation über den Netscaler ........................................................................15
Abbildung 11: Formularbasierte Anmeldung (Screenshot).............................................................16
Abbildung 12: Konsole mit Anweisung zur Debug-Ausgabe als Text (Screenshot) ........................17

Tabelle 1: Anforderungen an den ESXi-Server ................................................................................4

Tabelle 2: Konzeption der IP-Adressbereiche..................................................................................5
Tabelle 3: Personalplanung .............................................................................................................7
Tabelle 4: IP-Adressbereiche ..........................................................................................................8
Tabelle 5: Firewall-Regeln ...............................................................................................................9
Tabelle 6: DNAT-Regeln .................................................................................................................9
Tabelle 7: Projektzeitplanvergleich ................................................................................................18
Tabelle 8: Vergleich der Umsetzung mit den Rahmenbedingungen ..............................................19
Tabelle 9: Glossar .........................................................................................................................20

A3 Quellenverzeichnis
 Informationen zu Citrix Netscaler: https://www.citrix.de/products/netscaler-adc/
 Tutorials zur Ablösung von Forefront TMG durch Citrix Netscaler:
https://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/replacing-
microsoft-forefront-tmg-with-citrix-netscaler-for-website-publishing.pdf und
https://www.citrix.com/blogs/2013/12/19/tmg-replacement-for-exchange-2013-with-netscaler/
 FAQs zu Citrix Netscaler: https://www.citrix.com/support/
 Forum zu Citrix Netscaler: http://discussions.citrix.com/forum/1356-netscaler-application-
delivery-controller/
 Allgemein Informationen zu weiteren Begriffen: http://de.wikipedia.de

Alle Seiten wurden am 30.04.2017 letztmalig aufgerufen.

Miriam Knichalla Seite 21 von 21