Bei meinem aktuellen Arbeitgeber steht die Migration in zwei neue Rechenzentren an. Eines der Ziele dieser Migration ist die Erhöhung der Ausfallsicherheit. Dies habe ich zum Anlass genommen mir den PRTG Failover Cluster mit einem vorgeschalteten Citrix ADC einmal anzuschauen.

Die Installation und Konfiguration ist eigentlich recht einfach und das Vorgehen möchte ich in diesem Artikel nochmals erläutern.

PRTG Failover Cluster konfigurieren

Um den Core-Server von PRTG als Failover-Cluster zu konfigurieren gibt es seitens PAESSLER zwei gute Artikel:
– Failover Cluster Configuration
– Failover Cluster Step by Step

Wenn man sich an diese hält, läuft der Cluster in kürzester Zeit. Was gibt es zu beachten?

• Der zweite Cluster-Node ist immer Read-Only, d.h. selbst bei einem Ausfall des Master-Servers kann auf dem Failover-Server nur überwacht, jedoch nicht konfiguriert werden.
• Remote Probes müssen so (um-)konfiguriert werden, dass sie ihre Daten an alle Cluster Nodes senden und nicht nur dem Master.
• Die Remote Probes werden vom PRTG Cluster selbst konfiguriert. Eine allfällige Registry Anpassung (manuell oder via GPP) wird wieder überschrieben.
• Remote Probes müssen jeden Cluster Node einzeln erreichen können. Bei einer NAT Konfiguration bedeutet dies ein eigener FQDN und NAT Zugang pro Core Server.
• Der erste Administrator (prtgadmin) ist autonom pro Node. Um spätere Probleme zu vermeiden sollte das Passwort auf beiden Servern identisch gesetzt und mit der AD Authentifizierung gearbeitet werden.
• Nur der Master-Server sieht sich selbst noch als „Local Probe“. Auf den Failover-Servern ist nur der „Cluster Probe“ und alle anderen Remote Probe Server ersichtlich.
• Die Probe Dienste der PRTG Core Server senden ihre Daten nur lokal (127.0.0.1).

In den Cluster Einstellungen sollte man die „Node Namen“ passend setzen und die IP Adressen durch FQDN ersetzen.
Dies macht es einerseits übersichtlicher für alle PRTG Benutzer und andererseits ist man unabhängiger bei einer allfälligen Änderung der IP Adressierung.

Hinweise:
– Man kann zwar im GUI dem Master Server einen DNS Alias setzen, die Remote Probes erhalten jedoch immer den originalen Hostname übermittelt.
– Die Änderung wird sofort an die Remote Probes übermittelt.

Bei einer frischen Installation kann nun die Konfiguration direkt in der Cluster Probe gestartet werden. Wurde ein Solo PRTG Core Server in einen Cluster umgewandelt, so müssen die konfigurierten Gruppen, Geräte und Sensoren vomr „Local Probe“ in den „Cluster Probe“ verschoben werden:

Konfiguration Citrix ADC

Nachdem nun der PRTG Failover Cluster soweit konfiguriert ist, bauen wir nun den Zugriff auf diesen. Ohne ADC würde man nun entweder mittels DNS Round-Robin einen FQDN konfigurieren, wobei man hier nicht steuern kann auf welchem Node man landet, oder man arbeitet mit zwei verschiedenen FQDN, was wiederum nicht Anwenderfreundlich ist.

In diesem Abschnitt wird die Konfiguration eines LB vServer mit Failover Funktion erläutert.

Hierzu werden alle (normalerweise zwei) Cluster Nodes im ADC erfasst:

add server prtgserver1 prtgserver1.domain.pit
add server prtgserver2 prtgserver2.domain.pit

Für jeden Server erstellen wir einen Service. Nach best practice sind die PRTG Server SSL verschlüsselt, somit bauen wir passende Services dazu:

add service svc-https-prtgserver1 prtgserver1 SSL 443
add service svc-https-prtgserver2 prtgserver2 SSL 443

Im Gegensatz zu einem normalen Loadbalancing wird im Failover nicht ein einzelner sondern zwei vServer benötigt, um den zweiten als Backup zu konfigurieren. Dem vServer mit einer IP wird der Service des PRTG Master Servers angefügt. Der zweite vServer (ohne Adressierung) steuert den PRTG Failover Server an. Beide LB vServer benötigen auch das dazu passende SSL Zertifikat:

add lb vserver lb-vsrv-prtg.domain.pit SSL 192.168.200.222 443
add lb vserver lb-vsrv-prtg-backup.domain.pit SSL 0.0.0.0 0
 
bind lb vserver lb-vsrv-prtg.domain.pit svc-https-prtgserver1
bind lb vserver lb-vsrv-prtg-backup.domain.pit svc-https-prtgserver2

bind ssl vserver lb-vsrv-prtg.domain.pit -certkeyName wildcard.domain.pit
bind ssl vserver lb-vsrv-prtg-backup.domain.pit -certkeyName wildcard.domain.pit

set lb vserver lb-vsrv-prtg.domain.pit -backupVServer lb-vsrv-prtg-backup.domain.pit

Dem Service Monitoring habe ich am meisten Zeit gewidmet. Die PRTG Server bieten eine Status-Seite (/api/public/testlogin.htm), welche jedoch bereits bei einem Problem mit dem Mailserver ein „NOTOK“ zurück meldet.
Nur diese Status-Seite alleine konnte ich also nicht nutzen. Daher baute ich ein Monitoring basierend auf dieser plus zusätzlichen zwei Standard-Monitoren (TCP und HTTP). Da sich der TCP-Default Monitor nicht anfügen lässt wenn bereits ein anderer Monitor in Benutzung ist, habe ich einen eigenen erstellt.
Wegen der Benutzung von HTTPS muss dem HTTP Monitor der Response Code 302 hinzugefügt werden.

add lb monitor mon-prtg-TCP TCP
add lb monitor mon-prtg-http HTTP -respCode 200 302 -httpRequest "HEAD /" -secure YES

Das Monitoring der Status-Seite bat mir ein erstes Mal die Nutzung des „Reverse“ Monitorings. Würde man nämlich nur die Antwort „OK“ prüfen, so wäre der Monitor auch bei einem „NOTOK“ zufrieden, da „OK“ ein Bestandteil der Antwort ist. Daher prüfen wir auf ein „NOTOK“ und geben mit dem Monitor grünes Licht, falls diese Antwort nicht vorhanden ist – Reverse eben. ;-)

add lb monitor MON-PRTG-Core-Status HTTP-ECV -send "GET /api/public/testlogin.htm" -recv NOTOK -reverse YES -secure YES

Zu guter Letzt müssen die neu gebauten Monitore in den Services konfiguriert werden. Dazu fügen wir pro Service die drei hinzu und definieren den Monitoring Schwellwert 2. So bleibt der Service verfügbar, solange zwei Monitore grünes Licht geben:

bind service svc-https-prtgserver1 -monitorName mon-prtg-http
bind service svc-https-prtgserver1 -monitorName mon-prtg-TCP
bind service svc-https-prtgserver1 -monitorName mon-prtg-Core-Status
bind service svc-https-prtgserver2 -monitorName mon-prtg-http
bind service svc-https-prtgserver2 -monitorName mon-prtg-TCP
bind service svc-https-prtgserver2 -monitorName mon-prtg-Core-Status

set service svc-https-prtgserver1 -monThreshold 2
set service svc-https-prtgserver2 -monThreshold 2

Mit dieser Konfiguration kann nun ein Benutzer über eine FQDN (z.B. prtgcluster.domain.pit) auf die PRTG Oberfläche zugreifen. Der LB vServer vom ADC schaltet erst auf den Failover Server um, sobald der Master Server nicht mehr verfügbar ist (z.B. Neustart). Ist der Master Server wieder online, schaltet der ADC wieder auf diesen zurück.

Viel Spass beim Nachbauen. :-)

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