Citrix NetScaler Basiskonfiguration

Einen NetScaler in Betrieb zu nehmen und die erste Konfiguration wie NetScaler IP (NSIP), Subnet IP (SNIP), DNS Server, Timezone zu erstellen und den Lizenzfile auf die Appliance zu laden ist jetzt kein großes Problem. Alles das erledigt ein Assistent für uns. Allerdings hört die Konfiguration nach dem Assistenten noch nicht auf. Was dann noch alles zu beachten ist, möchte ich in diesem Beitrag einmal zeigen.

Sobald wir uns nach Fertigstellen des Assistenten und dem letzten Reboot wieder an der Konsole anmelden, sollten wir als erstes das Passwort des Superusers ändern. Das hört sich jetzt erst einmal banal an, ich finde aber immer wieder produktive NetScaler an denen man sich mit nsroot und dem Passwort nsroot anmelden kann.

Das Passwort ändern wir unter System -> User Administration -> User. Hier markieren wir den Benutzer nsroot und klicken auf den Button “Change Password”.

Das neue Passwort sollte ruhig etwas komplexer sein und an einem sicheren Platz gelagert werden, da wir dieses Konto später nicht mehr für die Anmeldung am NetScaler verwenden werden.

Administrative Tätigkeiten an Systemen wie dem NetScaler sollten nur mit personalisierten Accounts durchgeführt werden. Wir könnten hier natürlich Benutzerkonten als auch Gruppen direkt auf dem NetScaler lokal anlegen. Bei nur einem NetScaler vielleicht eine Möglichkeit, bei mehreren Systemen natürlich kein wirklich guter Weg. Da ein NetScaler ohnehin Authentifizierung für verschiedenste Dienste bereitstellen kann, können wir das auch für die Anmeldung am NetScaler nutzen.

In den meisten Umgebungen bietet sich das Active Directory einer Windows Domäne an. Mit einigen Besonderheiten können wir aber auch z.B. RADIUS für die Authentifizierung verwenden. Das bietet sich an, wenn der NetScaler in der DMZ installiert wurde und kein Zugriff auf das Active Directory aus diesem Segment gewünscht ist aber ein Radius Server existiert.

Normalerweise stellt allerdings in den meisten Unternehmensnetzwerken der Zugriff auf das Active Directory kein Problem dar. Aber auch hier die Anmerkung statt normalem LDAP (Port 389) doch lieber Secure LDAPS (Port 636) verwenden.

Zunächst legen wir dazu eine Sicherheitsgruppe im Active Directory an, in der sich alle Benutzer befinden, die später auch auf den NetScaler zugreifen dürfen. Da der NetScaler eine rollenbasierte Administration unterstützt, können das natürlich auch mehrere Gruppen sein. Diesen Gruppen weisen wir dann später entsprechende Berechtigungen im NetScaler zu.

Sobald die Gruppen angelegt sind, melden wir uns am NetScaler (noch mit dem Benutzer nsroot) an der WebGUI an. Unter System -> User Administration -> Group legen wir zunächst eine Gruppe an. Diese muss exakt den gleichen Namen wie die Gruppe im Active Directory habe (case sensitive).

Da die Mitglieder dieser Gruppe den Status “superuser” haben sollen, klicken wir unter Command Policies noch auf den Button “Bind”, wählen die superuser aus und klicken auf OK. Wir wählen hier natürlich keine Mitglieder aus, da wir diese später aus dem Active Directory verwenden werden.

Als nächstes machen wir uns an die Verbindung zum Active Directory. Wir sollten vorher allerdings sicherstellen, dass der NetScaler (genauer gesagt die NSIP) auch durch die Firewall mit dem Domänen Controller kommunizieren darf. Wollen wir mehrere Domänen Controller ansprechen, sollten wir vorher noch Load Balancing für LDAP bzw. LDAP/s konfigurieren. Dazu später mehr, die weitere Konfiguration ist aber unabhängig davon.

Unter System -> Authentication -> LDAP legen wir zunächst einen LDAP Server an.

Ich verwende gern sprechende Namen für Server und Services, dass macht das Arbeiten über das Command Line Interface oder über die Nitro API wesentlich einfacher.

Zunächst benötigen wir die IP-Adresse des Domänen Controllers (oder die des virtuelle Load Balancing Server). Wie bereits erwähnt, empfehle ich LDAP/S. Dafür wählen wir als Security Type SSL und als Port 636. Wer der Empfehlung nicht folgen möchte (oder kann) wählt hier PLAINTEXT und den Port 389. Der Server Type bleibt bei AD (Novell Benutzer können natürlich auch NDS wählen) und setzen den Haken bei Authentication. Der Time-out von 3 Sekunden kann so übernommen werden.

Unter den Connection Settings benötigen wir noch den Base DN in LDAP Schreibweise. Wir können hier direkt mit DC=Domain,DC=TLD auf das Verzeichnisroot zeigen. In großen Directories sollten wir aber etwas tiefer im Baum einsteigen. Jetzt noch den FQDN eines Benutzers der Berechtigungen im AD hat unter Administrator Bind DN eintragen und das Passwort dazu angeben. Seit Version 11.1 haben wir hier auch wieder einen “Test Connection” Button, um zu sehen ob alles richtig eingegeben wurde.

Unter “Other Settings” erfassen wir jetzt noch das Logon Attribute. Im Normalfall verwenden wir den SAMAccountName oder wer es gern Full Qualified mag, den UserPrincipalName. Im Search Filter erfasse ich gern noch einen tieferen Pfad zu der entsprechenden Gruppe, damit nicht eventuell andere Benutzer Zugriff auf den Netscaler erhalten. Das Format sieht zwar komisch aus, muss aber in der Form memberOf=CN=Gruppe,OU=GruppenOU,DC=Domain,DC=TLD angegeben werden. Das Group Attribute ist natürlich memberOf und das Sub Attribute cn. Die restlichen Felder belassen wir beim Standard.

Sollten in der Gruppe außer User Accounts auch Gruppen enthalten sein, dürfen wir nicht vergessen unter dem unscheinbaren More Link noch die Nested Group Extraction zu aktivieren. Abschließend wird das ganze noch mit OK gespeichert.

Der Server ist angelegt, nun benötigen wir noch eine Policy. Unter System -> Authentication -> LDAP können wir unter dem Tab Policies nun auch noch eine LDAP Policy anlegen. Diese benötigt neben einem sprechenden Namen noch die Auswahl des eben erstellten Servers sowie eine Expression. Da diese Policy immer “greifen” soll, verwenden wir hier ns_true.

Damit diese Kombination aus LDAP Policy und Server für die Anmeldung am Netscaler verwendet werden kann, müssen wir diese noch Global binden. Dazu klicken wir unter System -> Authentication -> LDAP auf den Button Global Bindings.

Hier wählen wir dann mit Add Binding unsere zuvor erstellte Policy aus, klicken auf Bind und speichern mit einem Klick auf Done das ganze ab. Neben unserer LDAP Policy sollte jetzt auch ein grüner Haken unter Globally Bound? erscheinen. Das war auch schon alles. Zukünftig können sich Mitglieder der angelegten AD Gruppe mit ihren Windows Credentials am NetScaler anmelden.

Wer es statt dem AD lieber einen RADIUS Server für die Authentifizierung verwenden möchte, kann diesen auf die gleiche Art einrichten. Also Radius Server und Policy unter System -> Authentication ->  Radius anlegen und Global binden. Wichtig an dieser Stelle ist jedoch, dass RADIUS in der Regel keine Gruppenmitgliedschaften auflösen kann. Hierfür müssen wir die Radius Group Extraction vorher noch konfigurieren. Das ist im folgenden Citrix Artikel relativ gut beschrieben.

Eigentlich stellt sich die Frage nicht wirklich, denn ohne SSL Verschlüsselung sollte keine Web GUI betrieben werden. Zuerst müssen wir den Netscaler natürlich dazu bewegen, ausschließlich verschlüsselte Verbindungen zu akzeptieren. Das Betrifft dann nicht nur die Web GUI sondern auch alle anderen Management-Tools (Telnet, SSH, FTP etc.). Die Konfiguration dazu erledigen wir unter System -> Network -> IPs. Hier wählen wir die NetScaler IP (NSIP) aus und klicken auf Edit. Wenn wir hier dann ganz nach unten scrollen, finden wir den Abschnitt Application Access Control. Hier setzen wir lediglich das Häkchen bei Secure Access Only und speichern das ganze mit OK ab.

Wichtig ist natürlich, dass der Haken bei Enable Management Access … nur bei der NSIP aktiviert ist. Auf allen anderen IP Adressen sollte der Management Access deaktiviert sein (außer natürlich, man hat einen wirklich sehr guten Grund es dort zu aktivieren).

Von nun an Verbinden wir uns ausschließlich über HTTPS mit unserem NetScaler. Was mich aber an dieser Stelle noch stört ist das selbstsignierte Zertifikat.

Ok, werden jetzt viele sagen. Der Netscaler ist ja nur intern zu erreichen und deshalb geht auch das selbstsignierte Zertifikat. Stimmt, aber es ist halt einfach nicht schön.

Was wir natürlich hierfür brauchen ist ein Server Zertifikat mit entsprechenden Root CA Zertifikat und dem privaten Schlüssel im PEM Format. Im Normalfall bekommen wir das von unserer internen Zertifizierungsstelle. Hier aber darauf achten, dass der Hostname des Netscaler auch im Zertifikat steht. In der Web GUI erfahren wir den Hostname am einfachsten über den Setup Wizard, den wir über das Zahnrad unter unserem Benutzernamen aufrufen können. Dort können wir ihn bei Bedarf auch ändern.

Über eine SSH Verbindung machen wir das mit show ns hostname an der Konsole. Geändert wird der Host Name dann mit set ns hostname hostname.domain.tld.

Wir sollten drei Dateien haben, das eigentliche Zertifikat, den privaten Schlüssel sowie das Root Zertifikat. Diese drei Dateien laden wir unter Traffic Management -> SSL -> Manage Certificates / Keys /CSRs auf unseren Netscaler.

Sobald diese Dateien auf den NetScaler hochgeladen wurden, können wir das Standard Zertifikat des NetScaler einfach austauschen. Unter Traffic Management -> Load Balancing -> Services finden wir unter der Karteikarte Internal Services erstmal alle Dienste, die das Standard Zertifikat verwenden (über das SSH CLI geht das übrigens mit dem Kommando show run | grep ns-server-certificate). Da wir jetzt nicht jeden einzelnen Service anfassen und das Zertifikat dort ändern wollen, ändern wir einfach das Zertifikat selbst.

Unter Traffic Management -> SSL -> Certificates -> Server Certificates finden wir das ns-server-certificate.

Dies können wir nun auswählen und mit einem Klick auf den Update Button einfach austauschen. Dazu aktivieren wir den Punkt Update the Certificate and key und wählen über den Button Choose File das zuvor hochgeladene Zertifikat und den privaten Schlüssel aus.

Wenn wir uns nun mit dem Hostnamen des Netscaler (richtiger DNS Eintrag vorausgesetzt) verbinden, wird nun keine Zertifikatswarnung mehr angezeigt.

Wer die zuvor beschriebene Konfiguration lieber auf der Konsole per SSH machen möchte, kann die folgenden Kommandos dazu verwenden:

Host Name setzen

set ns hostName <hostname.domain.tld>

NetScaler Gruppe hinzufügen

add system group <GruppenName> -timeout 3600

Command Policy binden

bind system group <GruppenName> -policyName superuser 100

LDAP Server erstellen

add authentication ldapAction <LDAP_Server_Name> -serverIP <IP_des_DCs> -serverPort 636 -ldapBase "dc=<domain>,dc=<tld>" -ldapBindDn <UserFQDN> -ldapBindDnPassword <Passwort> -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -nestedGroupExtraction ON -groupNameIdentifier sAMAccountName -groupSearchAttribute sAMAccountName

LDAP Policy erstellen und Server binden

add authentication ldapPolicy <LDAP_Policy_Name> NS_TRUE <LDAP_Server_Name>

LDAP Policy Global binden

bind system global <LDAP_Policy_Name> -priority 90

NetScaler Standardzertifikat austauschen

add ssl certKey ns-server-certificate -cert <Zertifkat_Name> -key <Private_Key_Name>

Für ganz faule geht das natürlich auch über die Nitro API des NetScaler z.B. mit PowerShell, aber das ist ein anderer Artikel.