Buch
- App-V Infrastruktur
- App-V Client
- App-V Sequenzierung
- Tools & Troubelshooting
- PowerShell mit App-V
Dies ist der vorletzte Teil und wir beschreiben eine hochverfügbare verschlüsselte App-V Infrastruktur mit einer Verschlüsselung nach außen.
Die Vorteile gegenüber einem Microsoft NLB sind, dass auch Services überwacht werden und auch das Lastverhalten berücksichtigt wird. Mit der Netscaler VPX Express Edition steht eine Kostenlose Lösung dafür mit bis zu 20 Mbit Bandbreite bereit.
In dieser Konfigurationsvorlage wird http im Backend gesprochen und SSL https nach außen.
Dazu muss zunächst die zuvor beschriebene Anleitung umgesetzt werden (Konfiguration des NetScaler Load Balancing). Anschließend geht es mit dem Import der Zertifikate werter.
Weitere Teile
Teil 1: App-V Infrastruktur mit Citrix NetScaler Load Balancing (optional Verschlüsselt)
Teil 2: App-V Infrastruktur mit Citrix NetScaler unverschlüsseltes App-V Load Balancing
Teil 3: App-V Infrastruktur mit Citrix NetScaler mit Verschlüsselung nach Außen
Teil 4: App-V Infrastruktur mit Citrix NetScaler und vollständiger Verschlüsselung
Der Port spielt diesmal keine Rolle. Wir nutzen in diesem Beispiel Port 4491
Für den Servernamen appv.uran.local und dem zugehörigen Stammzertifikat muss ein Zertifikat erzeugt worden sein.
Wir benötigen das Root Zertifikat der CA und ein Zertifikat für den virtuellen Server. Der Name (comman Name) des NLB soll appv.uran.local sein. Das Zertifikat wird in der CA erzeugt und muss mit dem privaten Schlüssel exportiert werden. Hier im pfx format für das Serverzertifikat und als als „cer“ ohne privaten Schlüssel für das Root. Im Folgenden Bild ist eine gültige Zertifikatkette zu erkennen
Anschließend muss das Rootzertifikat importiert werden. Die Prozedur entspricht der gerade durchgeführten nur ist kein Kennwort notwendig, da dass Stammzertifikat keinen privaten Schlüssel benötigt.
Es wird unter der gleichen IP Adresse wie für den http Zugriff ein neuer Virtueller Server angelegt. Diesmal mit dem Protokoll SSL.
In der Tat wird hier der neue Server mit der gleichen IP wie für den http Zugriff konfiguriert.
Für den https Zugang:
AppVHttps: 192.168.1.214 Port 4491
Anmerkung: Hier auch SSL/TSC eigentlich wird ein eigener Monitor benötigt
Wenn Services in einem Netzwerk bereitstellt werden, in denen das Kerberos-Protokoll zur gegenseitigen Authentifizierung verwendet wird, müssen Sie einen Dienstprinzipalnamen (SPN) für den Servicepunkt erstellt werden. Das AD weiß darüber über welches Konto eine Authentifizierung erfolgen kann.
Für jedes Konto und jeden Service darf ein solcher Eintrag nur einmal existieren.
Setspn -s http/<computername>.<domainname>:<port> <domain-account>
Optional, wenn noch kein Computerkonto „appv“ angelegt wurde
SPN https setzen
Anmerkung: Der Switch „-C“ verweist auf ein Computerkonto
setspn -C -A https/appv.uran.local:4491 uran\appv
Die Domäne "DC=uran,DC=local" wird überprüft.
Dienstprinzipalnamen (SPN) für CN=appv,OU=Servers,OU=uran,DC=uran,DC=local werden registriert.
https/appv.uran.local:4491
Aktualisiertes Objekt
Prüfen des SPN:
setspn -Q https/appv.uran.local:4491
Die Domäne "DC=uran,DC=local" wird überprüft.
CN=appv,OU=Servers,OU=uran,DC=uran,DC=local
https/appv.uran.local:4491
http/appv.uran.local:8091
Abschließend Services und Server herunterfahren. Der App-V Webservice appv.uran.local:4491 muss immer erreichbar bleiben
Kommentare