vCenter SSO nested groups

Das Modul vSphere Single-Signon (SSO) ist fester Bestandteil der vCenter Installation seit Version 5.1. Es ist ein zentraler Bestandteil und wird daher noch vor dem vCenter Dienst installiert. Justin King hat zum Thema eine sehr gute vierteilige Einführung im vSphere Blog (vmware) geschrieben. Updates von vCenter innerhalb der Version 5.1 hatten schon so einige Tücken, aber beim Upgrade auf Version 5.5 kann es je nach Strukturierung der Benutzergruppen zu Aussperrungen kommen.

Ausgesperrt

Beim Upgrade eines vCenter Servers von Version 5.1 auf 5.5 erlebte ich eine unangenehme Überraschung. Sämtliche vSphere Admins hatten nach dem Upgrade keinen Zugriff mehr auf den Cluster. Alle Benutzer waren Mitglieder der lokalen Admingruppe und als solche hätten sie vollen Zugriff auf vCenter haben müssen. Das Gegenteil war der Fall.

Fehlersuche

Fügte man einen Domänen Benutzer diskret hinzu, so erhielt er Zugriff. Als Mitglied einer Gruppe im Active-Directory konnten dem Benutzer ebenfalls Rechte zugeteilt werden. Der selbe Benutzer als Mitglied einer lokalen Gruppe erhielt keinen Zugriff. Offensichtlich kommt Single-Signon neuerdings nicht mehr mit geschachtelten Domänen Benutzern in lokalen Gruppen zurecht. Nach kurzer Suche wurde dies durch einen Artikel in den vmware-blogs bestätigt. Unter SSO Version 5.1 war dies noch problemlos möglich.

Vorsorge

Meine Empfehlung ist daher, vor dem Upgrade auf Version 5.5 zu kontrollieren, ob die Nutzerrechte über reine Active Directory Gruppen definiert sind. D.h. globale Gruppen mit ADS Usern.

Benutzer im Beispiel 1 erhalten Zugriff. Die selben Benutzer in einer lokalen Gruppe (Beispiel 2) erhalten keinen Zugriff. Das Problem sind hierbei nicht die lokalen Gruppen, sondern deren Verschachtelung mit Domänenbenutzern.

  1. vSphere-Admins (Sicherheitsgruppe, Domäne)
    • Domain\User1
    • Domain\User2
  2. Administratoren (Sicherheitsgruppe, lokal)
    • Domain\User1
    • Domain\User2

Links

 

vSphere SSO 5.5: Passwort Ablauf

Dass die Kennwörter für SSO Benutzer ein Ablaufdatum haben, hattew ich bereits in einem früheren Artikel berichtet. Man konnte das Problem elegant umgehen indem man die Standard Ablaufzeit (365 Tage) auf Null setzte (= unbegrent).

Bug oder Feature?

Ich versuchte, diese Einstellung auf einem frisch aktualisierten vCenter Server (5.5.0a) und bekam bei jedem Versuch eine Fehlermeldung ohne Information. „vSphere SSO 5.5: Passwort Ablauf“ weiterlesen

vSphere Webclient Sprache festlegen

Der vSphere Webclient passt sich automatisch an die Systemsprache des ClientOS an. Das ist zwar anwenderfreundlich, aber es gibt Situationen, in denen man gezielt eine andere Anzeigesprache haben möchte. So bringt mich beispielsweise ein Webclient in deutscher Sprache nicht weiter, wenn ich ein Problem im Internet recherchieren muss. Die Sprache der Wahl ist hier Englisch.

Es gibt in der GUI keine Option, die Sprache zu ändern. Man erledigt dies aber mit einem Zusatz zur URL beim Aufruf des Weblients.

URL Suffix

  • English:     /?locale=en_US
  • Deutsch:    /?locale=de_DE
  • Francais:   /?locale=fr_FR

Normale URL

https://myvcenter.domain.org:9443/vsphere-client/

Aufruf mit Sprachoption

https://myvcenter.domain.org:9443/vsphere-client/?locale=en_US

Links

DeepSecurity 9.0 und vSphere 5.5

Beim Updateversuch eines Testsystems (vSphere 5.1) auf Version 5.5 scheiterte das Upgrade der ESXi Hosts. Das betroffenen Hosts werden mit Trendmicro DeepSecurity 9.0 überwacht und enthalten daher auch die entsprechenden Kernelmodule. Da der Upgradeprozess auf anderen Systemen eine Routineaktion ist, war schnell der Kerneltreiber von DeepSecurity im Fokus.

Not supported

Nachfrage beim Trendmicro Support bestätigte die Vermutung:

  • Kein Support für DS 9 unter vSphere 5.5
  • Es wird keinen Patch für DS 9 geben
  • Komplett neue Architektur notwendig
  • DS 9.5 wird in Q2 2014 erscheinen (vermutlich April)
  • DS 9.5 wird nicht mit vSphere < 5.5 kompatibel sein

Das sind schlechte Nachrichten für Kunden von Trendmicro DeepSecurity. Als geschätzter Veröffentlichungstermin wird Q2/2014 (!) genannt. Besonders ärgerlich erscheint mir der letzte Satz. Es bedeutet im Umkehrschluss, daß eine Migration auf DS9.5 und anschließendes Upgrade auf ESXi 5.5 nicht möglich sein wird.

Alternativen?

Mittlerweile ist DeepSecurity nicht mehr das einzige Produkt mit Hypervisor basiertem Virenscan am Markt. McAfee und Kaspersky haben ebenfalls vergleichbare Produkte am Start. Wie ist die Situation bei der Konkurrenz?

McAfee

Das Aktuelle Produkt MOVE 3.0 Agentless ist nicht mit vSphere 5.5 kompatibel. Unterstützung ist für den nächsten Release geplant. Termin noch unbekannt.

Kaspersky

Kaspersky Security for Virtualization 2.0 unterstützt ebenfalls kein vSphere 5.5. Dazu ein Auszug aus den Software Requirements für Version 2.0.

For the File Anti-Virus component to work properly, the VMware virtual infrastructure must meet one of the following software requirements:

VMware ESXi 5.1, VMware ESXi 5.1 Update 1, VMware ESXi 5.0, VMware ESXi 5.0 Update 1, VMware ESXi 5.0 Update 2, or VMware ESXi 4.1 Update 3.

Links