Hallo zusammen

Wer schon mit Citrix Director gearbeitet hat, hat sich sicherlich auch schon darüber genervt, dass man die Domäne jedes Mal eintragen muss.
Von Citrix gibt es den Artikel CTX139896 in welchem beschrieben wird, wie man die Seiten im IIS dafür anpassen kann. Der Artikel verheimlicht jedoch, dass dies nach jedem Update des Directors zu wiederholen ist.

Warum also dieses Problemchen nicht mittels NetScaler lösen?

Im Artikel XML Dienste & Citrix Director gemeinsam hinter NetScaler habe ich ja bereits den Loadbalancer für den Director erstellt. Basierend auf diesem werde ich in diesem Artikel weiterfahren.

Ich wusste von anfang an, dass dies mit einer Rewrite Policy zu lösen ist, jedoch erbrachten meine Versuche lange nicht den gewünschten Erfolg. Nach einem Aufruf in der Community gab mir Carl Stalhood den notwendigen Input mit Verweis auf CTX122916 und die Problematik der IIS-seitigen Komprimierung. Nachdem es nun funktioniert, möchte ich nun die Schritte aufzeigen.

Zu Beginn sehen wir die Director Anmeldeseite mit drei leeren Feldern:

Im NetScaler müssen wir dann als erstes wie im Citrix Artikel CTX122916 beschrieben dem IIS mitteilen, dass wir keine komprimierten Antworten wollen. Dazu löschen wir den Header „Accept-Encoding“ aus den Anfragen mittels Rewrite Policy aus der heraus:

add rewrite action rw_act_DeleteAcceptEncodingHeader delete_http_header Accept-Encoding
add rewrite policy rw_pol_DeleteAcceptEncodingHeader HTTP.REQ.IS_VALID rw_act_DeleteAcceptEncodingHeader

Diese Rewrite Policy muss nun auf dem LB vServer bei jeder Anfrage ausgeführt werden:

bind lb vserver lb-vsrv-PIT-XD-HTTPS -policyName rw_pol_DeleteAcceptEncodingHeader -priority 100 -gotoPriorityExpression END -type REQUEST

Anschliessend müssen wir den „value“ Parameter gemäss CTX139896 in die LogOn.aspx ebenfalls mittels einer weiteren Rewrite Policy bei der Antwort einfügen:

add rewrite action rw_act_InsertDirectorDomain replace_all "HTTP.RES.BODY(120000).SET_TEXT_MODE(IGNORECASE)" q/"id=\"Domain\" value=\"domain.pit\""/ -pattern "id=\"Domain\""
add rewrite policy rw_pol_InsertDirectorDomain "HTTP.REQ.URL.SET_TEXT_MODE(ignorecase).CONTAINS(\"LogOn.aspx\")" rw_act_InsertDirectorDomain
bind lb vserver lb-vsrv-PIT-XD-HTTPS -policyName rw_pol_InsertDirectorDomain -priority 100 -gotoPriorityExpression END -type RESPONSE

Nach Abschluss dieser Arbeiten sieht das Resultat dann wie folgt aus:

Viel Erfolg beim Nachbauen :-)

Skript: NS-InsertDirectorDomain

Hallo zusammen

Immer wieder wird im Zusammenhang mit NetScaler die Frage gestellt: „Kann ich Ressourcen auch Gruppen zuweisen?“
Die Antwort ist kurz und bündig „Ja, man kann“, aber das wie und wo, das will ich in mehreren Artikeln ein wenig erläutern.
In diesem ersten will ich auf das wohl häufigste Szenario, dem NetScaler Gateway eingehen.

Auf die Einschränkung bei der Anmeldung möchte ich hier jedoch nicht eingehen. Dies ist in CTX111079 schon ausführlich beschrieben.

Viele kennen den NetScaler Gateway so, dass sie die virtuellen Server mittels Wizard aufsetzen, testen und für gut befinden. Daran gibt es kaum was auszusetzen. Wenn jedoch die Anforderungen wachsen und die Ressourcen (Session Policies) gemäss AD Gruppenmitgliedschaft zugewiesen werden sollen, dann funktioniert dies nicht mehr so sauber.

Das NetScaler System bietet uns hierzu ein paar gute Möglichkeiten. Bevor ich detaillierter auf so eine Konfiguration eingehe, möchte ich aber noch ein paar Worte zu den „Bind Points“ und Prioritäten verlieren.

Bind Points

Es gibt bei NetScaler Gateway vier Orte, wo wir die Session Policies binden können:
Benutzer –> Gruppen –> virtueller Server –> Global

Global:
Die globalen Einstellung sind zwar keine Session Policy, jedoch beinhalten sie die gleichen Einstellungen. Die globalen Einstellungen sind in der Hierarchie ganz unten und kommen somit erst zum Zug, wenn keine Session Policy was anderes definiert.

virtueller Server:
Beim der Zuweisung der Session Policies an einen virtuellen Server schränken wir dessen Aktionsradius auf diesen einen vServer ein. Dieser „Bind Point“ ist einer Hierarchie-Stufe höher wie die globalen Einstellungen.

Gruppen:
Es können Gruppen angelegt werden. Diese müssen exakt so wie in der AD geschrieben sein (case-sensitive). Diesen können Session Policies zugewiesen werden, welche dann nur für Mitglieder dieser Gruppe gelten. Die Gruppen haben die zweithöchste Hierarchie-Stufe.

Benutzer:
Es können auch Benutzer angelegt werden, welche wie die Gruppen mit der AD überein stimmen müssen. Diese haben die höchste Hierarchie-Stufe, sollten jedoch zur vereinfachten Administration höchstens zu Testzwecken benutzt werden.

Prioritäten

Wenn eine Policy zugewiesen wird, wird immer eine Priorität vergeben. Je kleiner die Nummer, desto höher die Priorität.
Gemeinerweise übersteuert die Priorität die soeben beschriebene Hierarchie der „Bind Points“, d.h. eine Policy gebunden an den vServer mit Prio 10 hat Vorrang einer Policy gebunden an eine Gruppe mit Prio 100.

Um dem Vorzubeugen habe ich mir persönlich angewöhnt mit Prioritätsbereichen zu arbeiten:
vServer: in Hunderterschritten 100, 200, 300, etc.
Gruppen: in Zehnerschritten: 10,20,30, etc.
Benutzer: in Einerschritten: 1,2,3, etc.
So sollte man sich selbst kein Bein stellen.

Beispielskonfiguration NetScaler Gateway

Im folgenden Beispiel will ich zwei verschiedene Session Policies (Apps Only / VPN) zwei verschiedenen Gruppen zuweisen. Ich gehe dabei davon aus, dass die Session Policies bereits erstellt sind und fokusiere mich nur um die Zuweisung auf die verschiedenen Gruppen.

Als erstes müssen die zwei Gruppen erstellt werden:

add aaa group G_PIT_AppsOnly
add aaa group G_PIT_VPNOnly

Anschliessend werden die vom Wizard erstellten Policies vom vServer entfernt:

unbind vpn vserver nsgw-vsrv-gateway.domain.pit -policy Policy01
unbind vpn vserver nsgw-vsrv-gateway.domain.pit -policy Policy02

Um im dritten Schritt die entsprechenden Policies den Gruppen zuzuweisen:

bind aaa group G_PIT_AppsOnly -policy SESPOL-AppsOnly
bind aaa group G_PIT_VPNOnly -policy SESPOL-VPNOnly

Viel Spass beim nachbauen :-)

Skript: NS-ResToGroup1

Hallo zusammen

Microsoft schafft es doch immer wieder zu beweisen, dass deren QS die Aufgabe nicht erfüllt.
Nachdem ich die letzten Windows Updates auf dem WSUS Server installiert hatte, kam ich nicht mehr auf den Server.

Was nun?

Nach einigen Recherchen fand ich dann endlich den notwendigen Input im Microsoft Forum, welcher in meinem Fall genützt hat:

• CMD als Administrator starten
• Unter %ProgramFiles%\Update Services\Tools den Befehl wsusutil.exe postinstall /servicing ausführen
• Im Server Manager das Feature HTTP Activation unter .NET Framework 4.5 Feature installieren
• WSUS Dienst neu starten

Danach funktionierte bei mir auch der WSUS wieder.

Viel Erfolg!

Hallo zusammen

Letztens wollte ich eine GPO nur für eine Gruppe freigeben.
So wie ich es früher immer anstellte, entfernte ich die „Authenticated Users“ und fügte meine Gruppe hinzu.
Das Resultat danach war ernüchternd. Die GPO wurde nicht angewandt mit dem Grund ‚unbekannt‘ (wie immer sehr hilfreich).

Nach ein wenig Suchen fand ich in einer Microsoft Diskussion einen Hinweis auf das Security Update MS16-072 welches genau diesen Fehler verursacht.
Die „Lösung“ aus dem Artikel ist so einfach wie wirkungsvoll.
Die zuvor entfernte Gruppe „Authenticated Users“ muss man wieder hinzufügen, jedoch nur mit Leserecht und nicht das Recht die GPO anzuwenden.

Danach läuft alles wieder wie man es gewohnt ist.

Im Artikel NetScaler Responder für Storefront habe ich darüber berichtet, wie man hinter einem Loadbalancer den Benutzer gleich auf die richtige Receiver for Web Seite weiterleiten kann. So wie es im Artikel beschrieben ist funktioniert dies wunderbar mit einem Browser, jedoch funktionieren die Accounting Services für den installierten Receiver nicht mehr.

Der Grund ist in der Expression der Responder Policy zu finden. Hier nochmals als Auffrischung die Policy vom genannten Artikel:

add responder policy Resp_Pol_to_SF-StoreWeb "HTTP.REQ.HOSTNAME.STARTSWITH(\"storefront\") && HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).CONTAINS(\"StoreWeb\").NOT" Resp_Act_to_SF-StoreWeb

Wir müssen dieser nun noch einen Ausschluss für die installierten Receiver hinzufügen:

add responder policy Resp_Pol_to_SF-StoreWeb "HTTP.REQ.HEADER(\"User-Agent\").CONTAINS(\"CitrixReceiver\").NOT&&HTTP.REQ.HOSTNAME.STARTSWITH(\"storefront\") && HTTP.REQ.URL.SET_TEXT_MODE(IGNORECASE).CONTAINS(\"StoreWeb\").NOT" Resp_Act_to_SF-StoreWeb

So funktioniert es dann für den Browser und die installierten Receiver.

Skript: NS-RespStorefront

Mit den SSL Labs von Qualys besteht die Möglichkeit ein Rating zur SSL Verschlüsselung seiner externen Zugriffe erstellen zu lassen. In diesem Artikel möchte ich diese Thematik im Zusammenhang mit NetScaler (Gateway) aufgreifen.

War bis und mit Firmware 10.1 das Standard-Rating eine F, so ist es seit Firmware 10.5 eine C:

Diese Rating Angaben geben uns einen Hinweis wie sicher die Verschlüsselung des NetScaler Gateways ist. Während F ein schlechtes Ergebnis darstellt ist C schon besser. Wir wollen uns die Ratings genauer betrachten und die Konfiguration optimieren um auf ein Rating von A bzw. A+ zu kommen.

Wenn man die erste Analyse genauer betrachtet, so findet man auch die Ursachen beschrieben:
– aktiviertes SSL3 sorgt für eine Abstufung zu B
– TLS 1.2 ist nicht aktiv, dies sorgt für eine Abstufung zu C
– aktivierte RC4 Cipher sorgen für eine Abstufung zu B
– PFS ist nicht aktiviert

Als erstes müssen wir eine virtuelle Appliance (VPX) auf den Firmware Stand von mindestens 10.5 Build 57.7 da vorher TLS 1.1 und TLS 1.2 nur auf der Hardware (MPX/SDX) unterstützt sind.
Nach dem Upgrade müssen im vServer in den SSL Parametern SSL3 deaktiviert sowie TLS 1.2 aktiviert werden.

set ssl vserver nsgw-vsrv-gateway.domain.pit -ssl3 DISABLED -tls12 ENABLED

Nach diesem Schritt wird unser Rating bereits auf ein B angehoben sein. Als weiteren Schritt kümmern wir uns um die Cipher sowie das Perfect Forward Secrecy (PFS).

Der erste Schritt hierbei ist die Erstellung einer neuen Cipher Gruppe:

add ssl cipher CIPHER-PIT
bind ssl cipher CIPHER-PIT -cipherName TLS1-ECDHE-RSA-AES256-SHA -cipherPriority 1
bind ssl cipher CIPHER-PIT -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA -cipherPriority 2
bind ssl cipher CIPHER-PIT -cipherName TLS1-AES-256-CBC-SHA -cipherPriority 3

Für das PFS wird weiter einen Diffie-Hellmann Schlüssel, welcher man via CLI erstellt, da das GUI in ein Timeout läuft:

create ssl dhparam dh-key-2048.key 2048 -gen 2

Wenn die Gruppe und der Schlüssel erstellt sind müssen wir diese nun noch im virtuellen Server konfigurieren:

bind ssl vserver nsgw-vsrv-gateway.domain.pit -cipherName CIPHER-PIT
set ssl vserver nsgw-vsrv-gateway.domain.pit -dh ENABLED -dhFile "/nsconfig/ssl/dh-key-2048.key" -dhCount 1000 -eRSA DISABLED

Nach dieser Einstellung ist unser Rating nun auf einem A:

Im Beispiel ist die Einstellung für das A+ bereits gesetzt aber ich möchte noch darauf eingehen. Vorher ist zu erwähnen, dass das Rating nicht höher wird solange das Intermediate Zertifikat nur SHA1 ist. Um die Wertung zu erhöhen muss einerseits das Intermediate Zertifikat eine höhere Signatur aufweisen sowie der HTTP Strict Transport Security Header gesetzt werden. Dies geschieht bei NetScaler mittels Rewrite Policy:

add rewrite action rw_act_InsertSTSHeader insert_http_header strict-transport-security "\"max-age=63072000; includeSubdomains; preload\"" -comment "strict-transport-security Header"
add rewrite policy rw_pol_InsertSTSHeader HTTP.RES.IS_VALID rw_act_InsertSTSHeader
bind vpn vserver nsgw-vsrv-gateway.domain.pit -policy rw_pol_InsertSTSHeader -priority 300 -gotoPriorityExpression END -type RESPONSE

Anschliessend ist die Bewertung auf einer A+:

Update vom 15.07.16

Wie es scheint, wurden die Prüfroutinen angepasst und unser NetScaler ist „nur“ noch mit einem A- bewertet. Im Report sieht man, dass die seit 10.5 ausgeschaltetet SSL Renegotiation als ‚Workaround‘ betitelt wird. Wenn wir diesen nun einfach komplett einschalten würden, wäre die Bewertung ein F (so war es nämlich vor 10.5). Wir müssen die SSL Konfiguration nun dahingehend ändern, dass nur unsichere SSL Renegotiations gesperrt werden:

set ssl parameter -delySSLReneg NONSECURE

BONUS:

Und wenn wir schon dabei sind, ist es evtl. sinnvoll einem Hacker die Webserver-Informationen nicht gleich auf dem Silbertablett zu präsentieren:

Um diesen Eintrag zu verschleiern verstecken wir diesen ebenfalls mittels zwei Rewrite Policies:

add rewrite action rw_act_DeleteServerHeader delete_http_header Server
add rewrite action rw_act_InsertServerHeader insert_http_header Server "\"unknown environment\""
add rewrite policy rw_pol_DeleteServerHeader HTTP.RES.IS_VALID rw_act_DeleteServerHeader
add rewrite policy rw_pol_InsertServerHeader HTTP.RES.IS_VALID rw_act_InsertServerHeader

bind vpn vserver nsgw-vsrv-gateway.domain.pit -policy rw_pol_DeleteServerHeader -priority 100 -gotoPriorityExpression NEXT -type RESPONSE
bind vpn vserver nsgw-vsrv-gateway.domain.pit -policy rw_pol_InsertServerHeader -priority 200 -gotoPriorityExpression NEXT -type RESPONSE

Das Ergebnis kombiniert mit dem STS Header von vorhin kann dann so aussehen:

Und nun viel Spass beim Nachbauen ;-)

Skript: NS-OptimizeSSL

Hallo zusammen

Wer mit Citrix Webinterface gross geworden ist kennt noch die verschiedenen Einstellungen zur Workspace Control.
Als Storefront herausgekommen ist, musste man dieses Feature in der web.config suchen. Mittlerweile ist es im GUI verfügbar aber leider noch nicht so wie wir es uns wünschen würden.

Bei genauerem Hinsehen stellt man fest, dass man nicht zwischen aktiven und getrennten Sitzungen unterscheiden kann.

Wie kann man dies nun lösen?

Diese Einstellungen sind auf dem Controller versteckt und genauer gesagt im Powershell.

Mittels PS können div. Policy Regeln konfiguriert werden, welche in diesem Citrix Blog in einer guten Übersicht beschrieben sind.

In meinem Artikel gehe ich nun einfach einmal auf die Anfrage eines Kunden ein, welcher nur getrennte Sitzungen übernehmen wollte.
Während den Recherchen wurde ich in einem Forumspost fündig, dass mit XA/XD 7.6 experimentel ein neuer Parameter hinzugefügt wurde.

Als erstes muss mittels Get-BrokerEntitelmentPolicyRule der Name der gewünschten Delivery Group evaluiert werden (kann vom Studio abweichend sein).

Anschliessend schauen wir uns die Einstellungen mittels Get-BrokerEntitelmentPolicyRule NameDerDeliveryGroup an:

Wir sehen bei SessionReconnect, dass durch den Parameter Always eine übernahme der Sitzung jederzeit erlaubt ist.

Mittels Set-BrokerEntitelmentPolicyRule NameDerDeliveryGroup -SessionReconnect DisconnectedOnly können wir die Einstellungen so setzten, dass nur eine getrennte Sitzung übernommen werden kann:

Mit einer erneuten Prüfung mit dem Befehl Get-BrokerEntitelmentPolicyRule NameDerDeliveryGroup sollte es nun so aussehen:

Ab jetzt werden nur noch getrennte Sitzungen übernommen.

Aktuell gibt es aber leider noch einen Wehmutstropfen: der Parameter ist nicht bei zugewiesenen Desktops (z.B. mit Personal vDisk) verfügbar. Ich hoffe jedoch schwer, dass Citrix uns diesen noch nachliefern wird.

Viel Spass beim Ausprobieren :-)

ab XenApp/XenDesktop 7.6

Hallo zusammen

Ich hatte das Vergnügen in den letzten Tagen meinen neuen Notebook in Empfang nehmen zu dürfen. Die Daten vom HP Elitebook 840 G3 kann jeder selbst im Internet nachlesen. Mir passen sie soweit, ausser dass ich statt den ausgelieferten 8GB RAM auf 16GB verdoppelte.

Der zusätzliche Speicher ist angekommen und ich wollte ihn „schnell“ mal einbauen. Im Vergleich zum G2 hat dieses Gerät jedoch keine Wartungsklappen mehr. Auch irgendwelche Harddisk-Einschübe sucht man vergebens. Nach ein bisschen Recherche und Ausprobieren habe ich es dann geschafft:

Schritt 1)
man finde alle Verschraubungen.
Bis auf eine Schraube sind alle unter Gumminoppen geschützt. Die letzte befindet sich im SD Slot, wozu man den blinden Einschub herausnehmen muss:

Schritt 2)
man entferne alle Gumminoppen und Schrauben.
Hier tut man sich selbst einen Gefallen, wenn man diese Teile sauber sortiert nach Schraublöchern ausbreitet. Es wäre zu einfach, wenn es zehn identische Noppen und elf identische Schrauben wären:

Schritt 3)
man entferne die Abdeckung.
Nachdem alle Schrauben entfernt wurden muss „nur“ noch die Abdeckung entfernt werden. Ohne Werkzeug (in meinem Fall Taschenmesser) und ein bisschen Mut zu ein wenig Gewalt kaum zu bewältigen. Anschliessend findet man eine übersichtliche und selbsterklärende Anordnung der Hardware vor:

Schritt 4)
man setze den RAM Baustein ein.
Dies ist nun einfach im Vergleich zu den vorherigen Schritten. Um keinen Elektronikschaden zu verursachen, sollte man die statische Ladung mit dem Notebook abgleichen (Stichwort: ESD):

Schritt 5)
Schritte 3 – 1 in umgekehrter Reihenfolge :-D
Bei den Gumminoppen darauf achten, dass die Schrägen wieder korrekt mit dem Gehäuse korrespondieren.

Weitere Schritte:
Wie in den Bildern bei Schritt 3 und 4 zu erkennen, ist im Notebook ein weiterer Festplattenplatz vorhanden.
Dies verleitet einen doch dazu eine zweite SSD einzubauen ;-)

Hallo zusammen und ein frohes neues Jahr :-)

Mir ist es schon letztes Jahr oft aufgefallen, dass beim Ausführen vom Server Cleanup Wizard innerhalb des Windows Server Update Service (WSUS) die Konsole in ein Timeout läuft. Ich hatte dies immer wieder auf die doch schon in die Jahre gekommene MMC Konsole geschoben. Dieses Jahr wollte ich endlich einmal die Serverbereinigung mittels Skript automatisieren und hatte da auch die Hoffnung, dass die Problematik nur ein GUI Problem sei, welches man über Skripting umgehen könnte. Leider war dies nicht der Fall und die Lösung kommt weiter unten…

Ich will es nicht verheimlichen, dass ich eigentlich alles zusammen kopiert habe. Jedoch will ich mit diesem Blog mehrere Beiträge zusammenfassen um den kompletten Weg einer automatisierten WSUS Bereinigung aufzuzeigen. Natürlich sind am Schluss alle Quellen genannt ;-)

Skript

Als erstes habe ich eigentlich nur nach den notwendigen PowerShell Befehlen gesucht und ich wurde dann auf wsus.de mit einem kompletten Skript fündig.
WSUS-Cleanup-Skript (Skript als Textdatei) / Link zur Quelle: http://www.wsus.de/serverbereinigung2

Das Skript müsst ihr nur noch mit euern Parametern (Servername, Maileinstellungen, Bereinigungsparametern, etc.) anpassen und schon könnt ihr es als Administrator ausführen (UAC lässt grüssen).

Geplanter Task

Als nächstes muss ein geplanter Task erstellt werden. Weil es mein erster mit PowerShell war, musste ich mich auch hier schlau machen.
Fündig wurde ich dann hier: http://www.metalogix.com/help/Content%20Matrix%20Console/SharePoint%20Edition/002_HowTo/004_SharePointActions/012_SchedulingPowerShell.htm

Zusammenfassend sind beim geplanten Task folgende Punkte zu beachten:
– ausführen ob Benutzer angemeldet ist oder nicht
– Benutzer des Tasks muss lokaler Administrator sein (Run as Admin)
– Ausgeführt wird PowerShell mit dem Skriptpfad als Argument

Timeout Problem

Bei einer grossen Menge an Updates wird der WSUS in ein Timeout laufen:

Um dem Abhilfe zu schaffen müsst ihr dieses Timeout im IIS anpassen:

IIS > Sites > WSUS Administration / Advanced Settings… / Limits > Connection Time-out (seconds)
Ich habe dieses bei meinem Server nun von 180 auf 3600 Sekunden erhöht und seither läuft die Bereinigung ohne Probleme.

Viel Erfolg beim Einrichten :-)

Quellen:

Home

http://www.metalogix.com
http://social.technet.microsoft.com

Hallo zusammen

Eine der Neuerungen mit NetScaler 11 war die Einführung des RDP Proxy. Ich habe mich im Rahmen einer Kursvorbereitung ein wenig mit dem Feature auseinander setzen dürfen/müssen. Nunja was soll ich sagen… es ist eigentlich gar keine Hexerei.

Vorraussetzungen: NetScaler Enterprise (RDP Proxy ist Bestandteil vom Unified Gateway) sowie NetScaler Gateway Universal Licenses

Wie ist funktioniert der RDP Proxy nun? Die komplette Grafik sieht nun so aus:

Die Skizze ist mit einer Unified Gateway Installation gezeichnet, wobei der NetScaler Gateway (NSGW) vServer ohne IP (0.0.0.0) hinter einem Content Switching (CS) vServer mit der entsprechenden VIP (z.B. 192.168.200.10) steht. In einer klassischen Konfiguration kann man den CS vServer weg denken und die VIP ist auf dem NSGW vServer konfiguriert.

Klassische CS Konfiguration:
– CS vServer hört auf die VIP
– Anfragen auf den Hostname webapps.domain.pit werden auf den Loadbalancing (LB) vServer der Webapplikationen geleitet
– Anfragen auf den Hostname rdp.domain.pit werden auf den NSGW vServer geleitet

Anfrage der Webapplikationen verlaufen ohne spezielle Konfigurationen direkt auf die Webserver der Applikationen.

Mittels RDP Server Profilen (z.B. rdp_server_pro) werden die Listener-Einstellungen wie FQDN unseres Gateway, Port, etc. konfiguriert.
Dieses „RDP Server Profile“ muss an den NSGW vServer gebunden werden, damit dieser neu auch auf Anfragen auf den konfigurierten Port reagiert.
Der Zugriff von extern muss nun nebst dem bekannten 443 Port auch den Port für die RDP Verbindung (Standard: 3389) gewährleistet sein.
Zugriffe werden nun auf dem NSGW vServer mit der entsprechenden VIP terminiert.

Update 04.05.16: nach neusten Erkenntnissen kann auch der Port 443 für die RDP Verbindung genutzt werden. Dabei muss jedoch Stand heute eine weitere IP verwendet werden. Gemäss Aussage von Citrix soll „Port Sharing“ in einer der nächsten Versionen funktionieren.

Update 08.07.16: Mit der neuen Version 11.1 funktioniert nun das „Port Sharing“ und man benötigt für einen RDP Proxy nur noch eine IP und kann alle Zugriffe via Port 443 konfigurieren (analog ICA Proxy).

Im „RDP Client Profile“ sind sämtliche für den Client relevanten Einstellungen hinterlegt wie z.B. die FQDN unseres Gateway, welche Mappings wir erlauben, etc.
Dieses Profile muss an eine Session Policy gebunden sein, welche wiederum entweder direkt dem NSGW vServer oder einer Gruppe/einem Benutzer zugeordnet ist.

Der RDP Client greift bei einem Aufruf der Verbindung direkt auf den NSGW vServer zu, dieser terminiert die Frontend RDP Verbindung und baut eine entsprechende RDP Verbindung zum gewünschten Backend Computer auf. Et voilà, so funktionierts… vereinfacht gesagt ;-)

Wie wird dies nun konfiguriert? Hier die Schritt-für-Schritt Anleitung in Form von CLI Kommandos (im GUI entsprechend abbilden):

Das RDP Proxy Feature muss separat aktiviert werden, falls nicht im Basis-Setup bereits geschehen:

enable feature RDPProxy

Nun müssen das RDP Client und Server Profile erstellt werden wobei der SharedKey bei beiden identisch sein müssen. Der Parameter -rdpFileName definiert nur, wie die Datei heisst, welche zum Client übermittelt werden soll:

add rdp clientprofile rdp_client_pro -rdpFileName pit.rdp -rdpHost rdp.domain.pit -psk Password1
add rdp serverprofile rdp_server_pro -rdpIP 192.168.200.10 -psk Password1

Nun muss das RDP Server Profile dem definierten NSGW vServer angebunden werden:

set vpn vserver nsgw-vsrv-rdp.domain.pit -rdpServerProfileName rdp_server_pro

Als nächstes benötigen wir entsprechende Session Policies in welchen wir den Zugriff erlauben, Clientless auf ALLOW setzen und das entsprechende RDP Client Profile zuweisen. Falls bereits Policies vorhanden sein sollten, können diese ggf. einfach angepasst werden:

add vpn sessionAction rdp_prof -defaultAuthorizationAction ALLOW -clientlessVpnMode ON -rdpClientProfileName rdp_client_pro
add vpn sessionPolicy rdp_pol ns_true rdp_prof

Diese Policies werden nun dem NSGW vServer angebunden:

bind vpn vserver nsgw-vsrv-rdp.domain.pit -policy rdp_pol -priority 100

Nach erfolgreicher Anmeldung wählt man den Clientless Access, sofern man nicht automatisch dahin geleitet wurde:

Mit der Eingabe https://FQDN-des-Gateways/rdpproxy/Ziel (z.B. https://rdp.domain.pit/rdpproxy/192.168.100.10) kann man sich nun eine RDP Verbindung via RDP Proxy aufbauen.
Bequemer für den Benutzer ist es, wenn man die Verbindungen als Bookmark erfasst und dem vServer bzw. den Gruppen zuweist:

add vpn url rdp_pitserver1 "PIT Server1" "rdp://192.168.100.11" -clientlessAccess ON
add vpn url rdp_pitserver2 "PIT Server2" "rdp://192.168.100.12" -clientlessAccess ON
add vpn url rdp_pitserver3 "PIT Server3" "rdp://192.168.100.13" -clientlessAccess ON
bind vpn vserver nsgw-vsrv-rdp.domain.pit -urlName rdp_pitserver1
bind vpn vserver nsgw-vsrv-rdp.domain.pit -urlName rdp_pitserver2
bind vpn vserver nsgw-vsrv-rdp.domain.pit -urlName rdp_pitserver3

So sieht ein Benutzer nach erfolgreicher Anmeldung direkt seine Server auf welche er sich mittels RDP verbinden kann:

Damit eine Verbindung erfolgreich aufgebaut werden kann, muss sich der angemeldete Benutzer überhaupt auch ohne Proxy via RDP anmelden können.
Der RDP Proxy macht ein Single-Sign-On und es erfolgt keine Benutzer/Passwort Abfrage mehr.

Nun wünsch ich euch viel Spass beim Nachbauen ;-)

Skript: NS-RDPProxy