Platform Services Controller und vCenter SSO: Konzept und Konfiguration

Jeder PSC ist stets mit einer vCenter Single Sign-On-Domäne verknüpft, wobei der Standard-Domänenname vsphere.local seit der Version 6.0 im zweiten Abschnitt des vCenter-Setup angepasst werden kann.

Der zugrunde liegende Verzeichnisdienst vmdir basiert auf LDAP. Sie können aber auch externe Identitätsquellen wie die Active Directory Domain Services (ADDS) einrichten. Dies geschieht im Web Client im Menü Verwaltung im Bereich Konfiguration im Tab Identitätsquellen. In der Spalte Domäne erkennen Sie, dass vsphere.local bereits eingerichtet ist.

Mit einem Klick auf das grüne +-Symbol können Sie weitere Identitätsquellen hinzufügen. Für ADDS wählen Sie hier Active Directory (Integrierte Windows-Authentifizierung), geben dann den Domänennamen ein und aktivieren die Option Maschinenkonto verwenden.

Voraussetzung dafür ist die Mitgliedschaft von vCenter Server in einer Windows-Domäne. Dies erfolgt im Menü Verwaltung unter Systemkonfiguration / Konten mit einem Klick auf das betreffende vCenter. Im Tab Verwalten finden Sie dann im Bereich Einstellungen im Abschnitt Active Directory die Möglichkeit, mit einem Klick auf Verknüpfen der gewünschten Domäne beizutreten. Danach starten Sie im Menü Aktionen den vCenter Server neu.

Die Domäne, also etwa vsphere.local oder eine ADDS-Domäne, bestimmt den Gültigkeits­bereich für die lokale Authentifizierung. Zudem können Sie die Domäne bei Bedarf in mehrere Sites aufteilen und jeden Platform Services Controller und jede vCenter Server-Instanz einer Site zuordnen. Dabei handelt es sich um ein logisches Konstrukt, das zum Beispiel geografische Standorte abbilden kann.

So funktioniert SSO

Bei einer Authentifizierung mit vCenter Single Sign On spielen Zertifikate eine wesentliche Rolle. Bevor Sie sich mit der Erzeugung und Verteilung von Zertifikaten befassen, müssen Sie verinnerlichen, wie die Authenti­fizierung via Single Sign On funktioniert.

vCenter Single Sign On fungiert dabei gleichermaßen als Authentifizierungs-Broker, besitzt aber auch eine Austausch­infrastruktur für Sicherheits-Token. Bei der Authentifizierung unterscheidet SSO allerdings zwischen menschlichen Benutzern und Lösungsbenutzern.

Beim initialen Handshake authentifizieren sich Benutzer nämlich mit einem Benutzernamen und einem Kennwort, während Lösungsbenutzer dazu ein Zertifikat verwenden.

Ist ein Benutzer erst am SSO authentifiziert, hat sich also beim Passieren der Eingangskontrolle quasi mit seinem Personalausweis ausgewiesen, dann können Sie ihn über das vCenter-Berechtigungs-Management mit Hilfe von Rollen und Berechtigungen für bestimmte Ausgaben autorisieren.

Der Handshake für Benutzer läuft dabei so ab, wie in folgender Abbildung, bei der PSC und vCenter deutlich als getrennte Komponenten zu erkennen sind - egal ob das PSC-Setup nun eingebettet oder verteilt ist. Bei der eingebetteten Architektur entfällt aber die Kommunikation zwischen PSC und vCenter über das Netzwerk.

1. Benutzer meldet sich mit Benutzername und Passwort am Web-Client an.
2. Der Web-Client leitet die Anmelde­informationen an SSO weiter, das dabei das SAML-Token des Web Clients prüft. Ist das Token gültig, überprüft SSO, ob der Benutzer in der konfigurierten Identitätsquelle existiert.
3. Kann sich der Benutzer bei der Identitätsquelle authentifizieren, gibt  SSO ein Token zurück. Dieses verwendet der vSphere Web Client ab jetzt als Benutzer und …
4. leitet das Token an den vCenter Server weiter.
5. Dieser prüft zusammen mit SSO, ob das Token noch gültig und nicht abgelaufen ist.
6. SSO gibt das Token wieder an vCenter zurück und nutzt dabei das Autorisierungssystem von vCenter, um den Benutzer die ihm erlaubten Zugriffs­möglichkeiten zu erteilen. Er kann sich damit authentifizieren und alle Objekte anzeigen und ändern, für die ihn seine Benutzerrolle berechtigt.

Handshake für Lösungsbenutzer

Anders schaut der Handshake bei so genannten Lösungs­benutzern aus. Sie sind Sets von Diensten, die in eine vCenter-Infrastruktur verwendet werden, wie etwa vCenter Server und Erweiterungen von VMware bzw. Drittanbietern, die sich ebenfalls mit Hilfe von vCenter SSO authentifizieren.

Hierbei hat SSO beim Übergang von der Version 5.5 zu 6.0 bedeutende Vereinfachungen erfahren. Musste nämlich vor vSphere 6.0 jeder Lösungsbenutzer über ein eigenes Zertifikat verfügen, konsolidiert VMware in vSphere 6.0 die vormals zahlreichen Services zu einer kleineren Gruppe von Lösungsbenutzern, was die Anzahl benötigter Zertifikate deutlich reduziert und damit deren Verwaltung vereinfacht.

Der Handshake für Lösungsbenutzer gestaltet sich dann wie folgt:

1. Der Lösungsbenutzer will eine Verbindung mit einem vCenter-Dienst herstellen.
2. Dazu wird er an vCenter SSO umgeleitet und muss, sofern er für SSO neu ist, ein gültiges Zertifikat vorweisen.
3. Ist das Zertifikat gültig, weist vCenter SSO  dem Lösungsbenutzer ein neues SAML-Token zu, das vom vCenter Single Sign On signiert wurde.
4. Der Lösungsbenutzer wird dann zu vCenter weitergeleitet und kann seinen Berechtigungen entsprechende Aufgaben ausführen. Muss sich der Lösungsbenutzer beim nächsten Mal authentifizieren, kann er direkt das SAML-Token zum Anmelden bei vCenter Server verwenden, ohne Umweg über SSO.