image_pdfimage_print

Sharefile StorageZone TLS Fehler

image_pdfimage_print

Nachdem die SAML Authentifizierung funktionierte, wollte ich die StorageZones konfigurieren.

Der erste Versuch mit der Restricted SZ scheiterte, bzw. mein Kollege riet aus div. Gründen davon ab, so dass ich diese nochmals ohne Restriktion einrichtete.
Diesmal lief es auch besser, nur wollte es noch immer nicht mit dem Upload der Daten funktionieren.

Wieder einmal über den Blog von Jason Samuel fand ich den richtigen Input: Link

Mit dem erwähnten Tool IIS Crypto konnte ich die Einstellungen vornehmen (TLS 1.2 deaktivieren) und entsprechend erfolgreich testen:

Quelle: Jason Samuel

Skript: NS-Sharefile

Sharefile SAML mit NetScaler Unified Gateway

image_pdfimage_print

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

XenDesktop 7.12 – und der Local Host Cache ist zurück

image_pdfimage_print

Hallo zusammen

Heute (07.12.16) ist die neue Version von XenApp/XenDesktop erschienen. Nebst vielen Neuerungen welche ihr hier nachlesen könnt, kam der Local Host Cache (LHC) zurück.

Mit diesem ist es nun wieder wie vor der Ära von Version 7.x möglich, dass der Betrieb einer XA/XD Umgebung weiterläuft, auch wenn die Verbindung zum SQL Server fehlschlägt. Im Gegensatz zum alten LHC, welcher von jedem XenApp Server lokal verwaltet (Access DB) und direkt angesteuert wurde, läuft der neue LHC in einer kleinen SQL Instanz (Local DB) und bei einem Ausfall des SQL Servers wird eine Instanz bestimmt, auf welche sich alle Controller verbinden. Da die verschiedenen LHC von den jeweiligen CCS parallel zum eigentlichen Betrieb aktuell gehalten werden, soll diese neue Variante auch einiges stabiler sein als der alte LHC.

Die Local DB ist bei einer Neuinstallation von XA/XD 7.12 standardmässig aktiv.

Bei einem Upgrade einer älteren Installation wo das Connection Leasing aktiv war, muss dieses noch deaktiviert und der LHC aktiviert werden:

Mehr und detailliertere Informationen findet ihr in den Docs.

Viel Spass beim Erfahrungen sammeln :-)