Citrix bietet zur Überwachung und Konfiguration von Citrix ADC (ehem. NetScaler) das Citrix Application Delivery Management (ehem. NetScaler MAS). Wie kann man nun aber die ADC Appliances im PRTG überwachen? Diese Frage haben sich schon einige gestellt und nebst kostenpflichtigen Plugins von www.prtgplugins.com gibt es weitere Open Source Optionen.

Eine mögliche Lösung habe ich bei Jason McKenry gefunden. Er hat basierend auf dem NetScaler PowerShell Modul passende Skripte erstellt, mit welchen aktuell folgendes überwacht werden kann:

• Appliance Performance (CPU, PE CPU, Disk, RAM und Durchsatz)
• Status aller vServer (LB, AAA, VPN und CS)
• Status aller LB vServer
• Ablaufdaten aller Zertifikate
• ungespeicherte Konfigurationen

Sein Blog-Artikel erklärt die komplette Konfiguration in Englisch. Ich möchte in diesem Artikel einerseits die Vorgehensweise auf Deutsch erläutern und andererseits noch ein paar Ergänzungen anbringen.

Als Basis dient nun jedoch der Blog-Artikel von Jason:

Quelle: https://itrandomness.com/2018/01/monitoring-netscaler-with-prtg/

Als erstes lädt man die passenden Skripte herunter. Dieser sind entweder auf GitHub (manchmal aktualisiert) oder am Ende des Artikels zu finden.

Nun muss das NetScaler Module installiert werden. Hierbei gibt es folgendes zu beachten:

• Ein aktuelles Windows Management Framework sollte installiert sein (muss manuell gemacht werden, nicht über die Microsoft Updates).
• PRTG arbeitet mit der 32-bit Version von PowerShell. Somit müssen alle Befehle in der (x86) Version ausgeführt werden.
• Das NetScaler Module muss auf allen Probe Server installiert werden, welche den Custom Sensor ausführen sollen.

Wenn alles rund läuft reichen folgende Befehle:

Set-ExecutionPolicy Unrestricted
Install-Module -Name NetScaler -scope AllUsers

Ich hatte auf meinem System das Problem, dass kein passender Provider gefunden wurde. Bei der Fehleranalyse stellte ich fest, dass im System kein Paket-Provider registriert war. Mit folgenden Befehlen kann dies korrigiert werden:

Install-PackageProvider Nuget –Force
Install-Module –Name PowerShellGet –Force

Damit wir die Appliances abfragen können, benötigen wir einen lokalen Benutzer auf jeder Appliance. Dieser benötigt nur Read-Only Rechte:

add system user svcprtg PASSWORD -externalAuth DISABLED
bind system user svcprtg read-only 100

Nun müssen die Sensor Dateien in die entsprechenden Ordner kopiert werden.

Die .ps1 Dateien kommen in den Ordner „Custom SensorsEXEXML“ (Standard: %programfiles(x86)%PRTG Network MonitorCustom SensorsEXEXML).

Die .ovl Dateien kommen in den Ordner „lookupscustom“ (Standard: %programfiles(x86)%PRTG Network Monitorlookupscustom).

Anschliessend müssen die Dateien (lookups) im PRTG neu geladen werden. Der Menüpunkt ist unter PRTG > Setup > Administrative Tools zu finden:

Bevor die Sensoren eingerichtet werden können, muss der neu erstellte Benutzer konfiguriert werden. Entweder gilt dieser nur für die ADC Appliances oder es ist eine Überlegung wert, den Benutzer für alle Linux/UNIX Server zu verwenden:

Nun können die fünf Sensoren (einer pro PowerShell Skript) eingerichtet werden. Diese werden als EXE/Script Advanced hinzugefügt. Der Name kann frei vergeben werden. Folgende Parameter müssen mitgegeben werden:

%host %linuxuser %linuxpassword

Hier ein paar Beispiele:

Falls seitens ADC vServer hinzugefügt oder entfernt werden, so muss der Sensor neu eingerichtet werden. Die Channels können dies nicht automatisch abgleichen.

Viel Spass beim Nachbauen. :-)

Die im letzten Beitrag vorgestellten Monitoring-Software PRTG von Paessler kann auf diverse Arten die Umgebung überwachen: Ping, WMI und natürlich auch SNMP. Mit WMI lässt sich zwar im Windows Umfeld viel Abfragen, jedoch geht dies zu Lasten der Leistung sowie die Zuverlässigkeit ist auch nicht immer gegeben. Schnell und zuverlässig hingegen funktioniert SNMP.
In diesem Artikel möchte ich kurz aufzeigen, wie dies im PRTG, Windows und div. anderen Produkten konfiguriert wird.

PRTG

Sinnvollerweise definiert man die SNMP Community auf höchster Ebene im PRTG, mittels Rechtsklick:

Anschliessend konfiguriert man die SNMP Community:

Die Einstellung wird über die komplette PRTG Hierachie vererbt, kann jedoch für einzelne Bereiche oder Geräte angepasst werden.

Windows (über GPO)

Damit SNMP bei Windows funktioniert muss das Feature SNMP Service / SNMP Dienst installiert werden, sofern nicht bereits geschehen.

Als weiteren Schritt konfiguriert man eine GPO, in welcher der Start vom SNMP Dienst sichergestellt und dieser konfiguriert wird:

Computer Configuration > Policies > Windows Settings > Security Settings > System Services > SNMP Service > Startup Mode: Automatic

Computer Configuraton > Policies > Administrative Templates > Network SNMP
> Specify Communites: die zuvor definierte Community (im Beispiel: prtgpit)
> Specify permitted managers: die IP vom PRTG Server sowie Localhost (127.0.0.1) damit der PRTG Server sich selbst abfragen darf
> Specify traps for public community: die zuvor definierte Community

Spätestens nach einem Neustart des SNMP Dienstes kann man nun im PRTG ein Autodiscovery auf diesem Server laufen lassen.

Citrix XenServer

Für den XenServer musste ich ein wenig forschen, bin dann aber im Blog von gimpland.org fündig geworden. Hier der entsprechende Auszug, der auch für XenServer 7.x Gültigkeit hat:

1. Bearbeite die Datei: /etc/sysconfig/iptables
   Nach der Linie “-A RH-Firewall-1-INPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT” folgende Einträge hinzufügen (müssen exakt so sein), der Kommentar dient zur visuellen Hilfe:

    # SNMP
    -A RH-Firewall-1-INPUT -p udp --dport 161 -j ACCEPT
    -A RH-Firewall-1-INPUT -p udp --dport 162 -j ACCEPT

2. Die XenServer interne Firewall neu starten: service iptables restart
3. Bearbeite die SNMP Konfiguration:  /etc/snmp/snmpd.conf und ändere den public Community string in die zuvor definierte Community

    # First, map the community name "public" into a "security name"
    # sec.name source community
    com2sec notConfigUser default public

4. Aktivieren und Einlesen der SNMP Konfiguration: chkconfig snmpd on
5. Neustart vom XenServer SNMP Dienst: service snmpd restart

Dieser Vorgang muss für jeden XenServer Host durchgeführt werden.

Anschliessend kann man auch hier im PRTG ein Autodiscovery auf den XenServern starten und abwarten.

Citrix NetScaler

In der NetScaler GUI kann man einfach die Community und die Manager eintragen. Ist meines Erachtens sehr selbsterklärend.
Ich führe hier deshalb die CLI Befehle auf (prtgpit ist die definierte Community und 192.168.100.79 der PRTG Server):

add snmp community prtgpit ALL
add snmp trap generic 192.168.100.79 -communityName prtgpit
add snmp trap specific 192.168.100.79 -communityName prtgpit -severity Warning

Weiter können im GUI oder via CLI die einzelnen SNMP Alarme ein-/ausgeschaltet sowie die Schwellwerte dafür konfiguriert werden.

ZyXEL ZyWALL USG-20

In der ZyWALL Konfiguration findet man die SNMP Einstellungen unter Configuration > System > SNMP:

Analog wie hier aufgeführt sind andere Geräte zu konfigurieren.

Viel Spass Nachbauen :-)

Ich bin mich wieder frisch am Einarbeiten in das Thema Exchange.

Das Grundsetup mit Exchange 2016 habe ich recht schnell hingekriegt und auch den externen Zugang via NetScaler war dank eines Skriptes von meinem Kollegen einfach hergestellt. Nun wollte ich jedoch noch für div. Dienste einen einfachen internen SMTP Relay Server erstellen.

Eine erste Anleitung dazu fand ich dann relativ schnell bei Paul Cunningham (Link).

Leider funktionierte dies nicht ganz so im Web GUI. Der Grund lag einfach gesagt an einem Bug von Microsoft und die Lösung war Powershell. Die Anleitung dazu fand ich dann bei Jeff Guillet (Link).

Nun funktionierte mein SMTP Relay zwar wenn ich den Exchange Server direkt ansteuerte, jedoch nicht via NetScaler. Und dies wollte ich dann auch noch lösen:

Die Ursache warum ich via die bereits eingerichtete NetScaler Konfiguration den SMTP Relay nicht ansteuern konnte war mir recht schnell klar. Der Exchange Server unterscheidet die Empfangskonnektoren jeweils anhand der Quell-IP und via NetScaler ist dies immer die SNIP.

Was musste nun getan werden?

Dem Exchange Server müssen verschiedene Quellen vorgegaukelt werden. Im NetScaler kann dies mittels einer weiteren SNIP eingerichtet werden. Wichtig hierbei ist jedoch, dass die jeweiligen SNIP Adressen den richtigen vServern mittels Net Profiles zugewiesen werden, da ansonsten die Appliance mittels Round Robin die SNIP wechselt.

Schritt 1 – Erstellen einer weiteren SNIP und Konfiguration der Net Profiles:

add ns ip 192.168.100.12 255.255.255.0 -vServer DISABLED -gui DISABLED
add netProfile NP-192.168.100.11 -srcIP 192.168.100.11
add netProfile NP-192.168.100.12 -srcIP 192.168.100.12

Schritt 2 – Erstellen eines weiteren LB vServers für den SMTP Relay:

add lb vserver lb-vsrv-mailrelay.domain.pit-SMTP TCP 192.168.100.90 25 -persistenceType NONE
bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP svc-smtp-pitex01

Schritt 3 – Net Profiles den LB vServern korrekt zuweisen:

set lb vserver lb-vsrv-mail.domain.pit-SMTP -netprofile NP-192.168.100.11
set lb vserver lb-vsrv-mailrelay.domain.pit-SMTP -netprofile NP-192.168.100.12

Schritt 4 – Empfangskonnektor für SMTP mit neuer SNIP konfigurieren:

Und nun viel Spass beim Nachbauen :-)

Quellen: The EXPTA {blog} & exchangeserverpro.com

Skript: NS-ExSMTPRelay

In meiner kleinen Demo-/Testumgebung wollte ich Sharefile mit SAML Authentifizierung mittels NetScaler Unified Gateway einrichten.

Ich fand schnell eine brauchbare Anleitung im Blog von Jason Samuel (Link)

Anders wie in seinem Artikel beschrieben verwende ich keinen AAA vServer sondern die Authentifizierung findet an einem NetScaler Gateway vServer statt.
Zu beginn scheiterte ich jedoch kläglich im Test, bis ich mit meinem Kollegen auf eine Stolperfalle in der Sharefile Control Plane gestossen bin.
Nachdem alle Einstellungen vorgenommen und gespeichert wurden, darf man nicht mehr auf „SAVE“ klicken, da sonst das SP Zertifikat neu generiert wird:

Weiter sollte man die Web-Authentifizierung deaktivieren, da sonst in den Plugins die Webseite aufgebaut wird, anstelle der Plugin-Funktion.

Um das eigene SAML Zertifikat nicht zu oft aktualisieren zu müssen, kann das IDP (x.509) Zertifkat auch von einer internen CA mit längerer Dauer ausgestellt worden sein und muss nicht zwingend mit dem FQDN des IDP übereinstimmen:

Quelle: www.jasonsamuel.com

Skript: NS-Sharefile

Seit NetScaler 11.x ist das Customizing der Anmeldeseite vom NetScaler Gateway richtig komfortabel geworden.
Innerhalb des GUIs wird man Schritt für Schritt durch alle Punkte durchgelotst und man kann eine Sprache definieren um die Textfelder wunschgemäss anzupassen.

Was nun aber, wenn man damit rechnen muss/darf, dass Zugriffe mit verschiedenen Browsersprachen geschehen? Zum Beispiel in mehrsprachigen Ländern wie der Schweiz oder bei global tätigen Firmen? Oder auch was ist wenn man detailliertere Anpassungen tätigen will, als dass das GUI einem zur Verfügung stellt?

Diesen Fragen gehen wir nun ein wenig genauer auf den Punkt:

Schritt 1 – neues Portal Theme im GUI erstellen

NetScaler Gateway > Portal Themes > Add

Dem Theme einen Namen geben und eine entsprechende Vorlage auswählen

Die ersten Einstellungen beschreibe ich hier nicht weiter. Es geht im Wesentlichen um Farben und Hintergrundbilder.
Die Vorgehensweise wurde schon in div. anderen Foren beschrieben.

Im Abschluss dieser Einstellungen wählt man die Hauptsprache aus.

Schritt 2 – Textfelder im GUI anpassen

In den meisten Fällen werden die Textfelder der Anmeldeseite (Login Page) sowie der anschliessenden Clientless Seite (Home Page) angepasst:

Der „Page Title“ definiert den Seitentitel, welcher im Browser im Tab dargestellt wird.
Der „Form Title“ ist die Aufforderung zur Anmeldung, welcher z.B. durch eine firmenspezifische Willkommensformel ersetzt werden kann.
Der „Password Field2 Title“ ist i.d.R. das Feld für die Tokeneingabe (z.B. RSA oder SafeWord).
Hinter dem „Applications Tab Label“ findet der Benutzer seine Applikationen und Desktops der XenApp/XenDesktop Umgebung.

Schritt 3 – Anpassung weiterer Textfelder in den Sprachdateien

Unter /var/netscaler/logon/themes befinden sich sämtliche Themes, auch das vorher erstellte.

Unter /var/netscaler/logon/themes/ThemeName/resources sind die Sprachdateien zu finden.
In den einzelnen Dateien finden wir sämtliche Textfelder, welche wir nun zusätzlich zum GUI bzw. in anderen Sprachen anpassen können.

Schritt 4 – weiteres Customizing in der custom.css

Im Ordner /var/netscaler/logon/themes/ThemeName/css finden wir u.a. die custom.css
In dieser können wir nun weitere Anpassungen der Formatierung analog dem Customizing von Storefront 3.x vornehmen.

Viel Spass beim Nachbauen :-)

Hallo zusammen

In den letzten beiden Artikel der Serie haben wir ein wenig die Möglichkeiten der Ressourcenzuweisung mit NetScaler Gateway sowie einer Gruppe mit Authorization Policies erläutert.
Was ist nun aber, wenn beim Anmelden via AAA mehrere oder gar verschachtelte Gruppen Zugriff erhalten sollen.

Dies wollen wir uns nun ein wenig genauer anschauen.

Als Basis für den Artikel dient uns der letzte, weshalb am Schluss auch beide Skriptdateien zur Verfügung stehen. Die Differenzen zum letzten Artikel sind zusätzlich rot hervorgehoben.

Nehmen wir uns als erstes die verschachtelten Gruppen (nested Groups) einmal vor. Damit dies funktioniert muss die LDAP Abfrage ein wenig erweitert werden. Innerhalb des GUIs findet man dies unter LDAP > Servers > euer LDAP Server > „More“
Hier kann man die Gruppenextrahierung aktivieren, die maximale Verschachtelungstiefe definieren (hoffentlich nicht zu tief), sowie die Attribute konfigurieren. Erstellt man den LDAP Server mittels CLI sieht es folgendermassen aus:

add authentication ldapAction ldap-srv-PIT -serverIP 192.168.100.50 -serverPort 389 -ldapBase "dc=domain,dc=pit" -ldapBindDn svcldap@domain.pit -ldapBindDnPassword Password1 -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -nestedGroupExtraction ON -maxNestingLevel 3 -groupNameIdentifier sAMAccountName -groupSearchAttribute memberOf -groupSearchSubAttribute CN

Ab jetzt werden auch die verschachtelten Gruppen aufgelöst. Prüfen kann man dies mittels dem Tool aaad.debug

Für die erlaubte Anmeldung mehrerer Gruppen beschreibe ich hier vier Varianten. Bei diesen gehen wir davon aus, dass nebst der bekannten Gruppe G_PIT_Backend auch die Gruppen L_PIT_Intranet und U_PIT_VIPs Zugriff erhalten sollen.

Variante 1 / für jede Gruppe eine Policy

Die erste Variante ist zwar einfach, jedoch mit Fleissarbeit und der Gefahr der Unübersichtlichkeit verbunden. Wir erstellen für jede einzelne Gruppe eine Policy und fügen sie dem LB vServer hinzu. Es gilt hier vor allem auch auf die Prioritäten zu achten!

add authorization policy IntranetBackendAllow-G_PIT_Backend "HTTP.REQ.USER.IS_MEMBER_OF(\"G_PIT_Backend\")" ALLOW
add authorization policy IntranetBackendAllow-L_PIT_Backend "HTTP.REQ.USER.IS_MEMBER_OF(\"L_PIT_Backend\")" ALLOW
add authorization policy IntranetBackendAllow-U_PIT_VIPs "HTTP.REQ.USER.IS_MEMBER_OF(\"U_PIT_VIPs\")" ALLOW
bind lb vserver LB-vsrv-intranet.domain.pit -policyName IntranetBackendAllow-G_PIT_Backend -priority 100 -gotoPriorityExpression END -type REQUEST
bind lb vserver LB-vsrv-intranet.domain.pit -policyName IntranetBackendAllow-L_PIT_Backend -priority 200 -gotoPriorityExpression END -type REQUEST
bind lb vserver LB-vsrv-intranet.domain.pit -policyName IntranetBackendAllow-U_PIT_VIPs -priority 300 -gotoPriorityExpression END -type REQUEST
bind lb vserver LB-vsrv-intranet.domain.pit -policyName DenyAll -priority 1000 -gotoPriorityExpression END -type REQUEST

Variante 2 / sämtliche Gruppenabfragen in einer Policy (Inbound Expression)

In dieser zweiten Variante fragen wir sämtliche Gruppen in der Policy-Expression ab. Vorteil der Variante ist ein einziger Konfigurationsort – Nachteil ist jedoch, dass die Abfragen nicht wiederverwendet werden können im Gegensatz zu Variante 3 und 4.

add authorization policy IntranetBackendAllow "HTTP.REQ.USER.IS_MEMBER_OF(\"G_PIT_Backend\")||HTTP.REQ.USER.IS_MEMBER_OF(\"L_PIT_Backend\")||HTTP.REQ.USER.IS_MEMBER_OF(\"U_PIT_VIPs\")" ALLOW

Variante 3 / pro Gruppe eine eigene Expression

In der dritten Variante erstellt man pro Gruppenabfrage eine Expression (im GUI unter AppExpert) und verbindet diese dann in der Policy:

add policy expression IS_G_PIT_Backend "HTTP.REQ.USER.IS_MEMBER_OF(\"G_PIT_Backend\")"
add policy expression IS_L_PIT_Backend "HTTP.REQ.USER.IS_MEMBER_OF(\"L_PIT_Backend\")"
add policy expression IS_U_PIT_VIPs "HTTP.REQ.USER.IS_MEMBER_OF(\"U_PIT_VIPs\")"
add authorization policy IntranetBackendAllow "IS_G_PIT_Backend || IS_L_PIT_Backend || IS_U_PIT_VIPs" ALLOW

Variante 4 / sämtliche Gruppenabfragen in einer Expression

Wie in Variante zwei können sämtliche Gruppenabfragen in einer Expression erledigt und die Abfrage kann in mehreren Policies verwendet werden:

add policy expression IS_AllowForBackend "HTTP.REQ.USER.IS_MEMBER_OF(\"G_PIT_Backend\")||HTTP.REQ.USER.IS_MEMBER_OF(\"L_PIT_Backend\")||HTTP.REQ.USER.IS_MEMBER_OF(\"U_PIT_VIPs\")"
add authorization policy IntranetBackendAllow "IS_AllowForBackend" ALLOW

Ich persönlich bevorzuge die Variante 3 da die Abfragen mehrfach und in verschiedenen Konstellationen wiederverwendet werden können.

Skripte: NS-ResToGroup2 & NS-ResToGroup3

Hallo zusammen

Im letzten Artikel ging ich auf die Zuweisung von Session Policies an Gruppen innerhalb NetScaler Gateway ein. Auch wenn dieser dem einen oder anderen Leser vielleicht sehr banal vorkam, so wird dies in Kursen und im Support öfter mal angefragt.

In diesem Artikel wollen wir uns die Möglichkeiten anschauen, Authorization Policies des AAA Features aufgrund Gruppenmitgliedschaften ausführen zu lassen.

Zwar gibt es verlockenderweise auch Gruppen und Benutzer:

Und man erhält sogar die Option um Authorization Policies zuzuweisen, jedoch wird man bald an einer Fehlermeldung scheitern :-(

Somit ist diese Möglichkeit leider eben deren keine.

Wir müssen also auf eine andere Variante zurückgreifen und zwar auf die Expressions. Bevor ich diese genauer erläutere, bauen wir uns erst ein Szenario:

Gehen wir davon aus, dass wir einen bestimmten Backendservice mittels LB bereitstellen und zusätzlich mittels AAA (ohne SSO) absichern wollen.
Die Anmeldung erfolgt via LDAP und die Gruppen werden entsprechend ermittelt.
Die Gruppe G_PIT_Backend soll Zugriff erhalten, während den restlichen Benutzer der Zugriff verweigert werden soll.

Als erstes erstellen wir die LDAP Server und Policy inkl. Ermittlung der Gruppen:

add authentication ldapAction ldap-srv-PIT -serverIP 192.168.100.50 -serverPort 389 -ldapBase "dc=domain,dc=pit" -ldapBindDn svcldap@domain.pit -ldapBindDnPassword Password1 -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn
add authentication ldapPolicy ldap-pol-PIT ns_true ldap-srv-PIT

Im weiteren Schritt wird der AAA vServer für die spätere Authentifizierung erstellt:

add authentication vserver aaa-vsrv-aaa.domain.pit SSL 192.168.200.50 443
bind authentication vserver aaa-vsrv-aaa.domain.pit -policy ldap-pol-PIT -priority 100
bind ssl vserver aaa-vsrv-aaa.domain.pit -certkeyName aaa.domain.pit

Nun können wir wie gewohnt unseren Backendservice mittels LB bereitstellen, jedoch zusätzlich den AAA vServer zur Authentifizierung hinzufügen:

add server INTRANET01 192.168.100.81
add server INTRANET02 192.168.100.82
add service svc-https-intranet01 INTRANET01 SSL 443
add service svc-https-intranet02 INTRANET02 SSL 443
add lb vserver lb-vsrv-intranet.domain.pit SSL 192.168.200.80 443 -persistenceType COOKIEINSERT -persistenceBackup SOURCEIP -AuthenticationHost aaa.domain.pit -Authentication ON -authnVsName aaa-vsrv-aaa.domain.pit
bind lb vserver lb-vsrv-intranet.domain.pit svc-https-intranet01
bind lb vserver lb-vsrv-intranet.domain.pit svc-https-intranet02
bind lb vserver lb-vsrv-intranet.domain.pit -certkeyName intranet.domain.pit

Nach einem ersten Test stellen wir nun fest, dass die Authentifizierung funktioniert. Jedoch erhält aktuell noch jeder Benutzer Zugriff ins Backend.

Um die Zugriffe ins Backend zu steuern erstellen wir nun zwei Authorization Policies, wobei die eine alles sperrt und die andere den Zugriff für unsere Gruppe gewährt:

add authorization policy DenyAll HTTP.REQ.IS_VALID DENY
add authorization policy IntranetBackendAllow "HTTP.REQ.USER.IS_MEMBER_OF(\"G_PIT_Backend\")" ALLOW

Diese Policies müssen wir nun noch in der richtigen (!) Priorität dem vorhin erstellen LB vServer zuweisen:

bind lb vserver LB-vsrv-intranet.domain.pit -policyName IntranetBackendAllow -priority 100 -gotoPriorityExpression END -type REQUEST
bind lb vserver LB-vsrv-intranet.domain.pit -policyName DenyAll -priority 200 -gotoPriorityExpression END -type REQUEST

Ab jetzt erhalten nur noch die Mitglieder unserer definierten Gruppe den Zugriff ins Backend.

Viel Erfolg beim Nachbauen. :-)

Skript: NS-ResToGroup2

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

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