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