SeeTricks - Gedanken, Links, Tools und Skripte rund um Citrix Produkte

Um sich an einem XenServer nicht immer als User "root" anmelden zu müssen oder sogar das Kennwort mit Arbeitskollegen teilen zu müssen, kann man ja den XenServer / Pool mit dem Active Directory verbinden und das "role-based access" (RBAC) Konzept benutzen, um AD-User oder -Gruppen mit bestimmten Rollen und Rechten zu versehen. Dies funktioniert allerdings nur in der lizenzierten Version von XenServer und erfordert Rechte im AD für den Beitritt der XenServer aus dem Pool. Wem dies zuviel ist, der kann sich auch einen weiteren lokalen User (wie "root) anlegen, um sich am XenServer anzumelden. Dazu muss auf der Shell des XenServers zunächst ein User angelegt werden, der sich prinzipiell anmelden kann und ggf. mit den passenden Rechten ausgestattet ist. Danach ist der Zugriff dieses Users auf die Managementschnittstelle zum XenServer, die XAPI, zu regeln. Los geht's - am Beispiel des Users "lurch": User auf der Shell des XenServer Hosts anle

Was soll da schon passieren? Das denken sich wohl viele Admins, wenn es an die Frage geht, ob der XML Port des Delivery Controllers (oder ggf. Cloud Connectors) TLS verschlüsselt werden sollte. Immerhin hat man doch schon den Zugriff auf NetScaler und StoreFront durchgängig mit Zertifikaten gesichert... Ein Restrisiko bleibt, denn immerhin gehen zwar per default keine Benutzernamen und Passwörter im Klartext über diesen Port, doch die Kommunikation zwischen StoreFront und den Delivery Controllers bzw. Cloud Connectors beinhaltet den Sessionkey für jede ausgehandelte Sitzung. Und wenn es einem Angreifer gelingt die Obfuskation der Daten (Richtig gelesen, Citrix verschlüsselt hier nicht, sondern lässt die Daten lediglich in anderen Daten "verstecken". Etwa so, wie seine Pin als Telefonnummer getarnt auf die Kreditkarte zu schreiben...mag reichen, oder eben nicht) zu verstehen (fertige Plugins sind im Netz erhältlich), dann könnte dieser Angreifer mit dem Sessionkey eine best