Moderne vCenter-Anmeldung mit ADFS (2)

Lesezeit
5 Minuten
Bis jetzt gelesen

Moderne vCenter-Anmeldung mit ADFS (2)

10.04.2023 - 09:30
Veröffentlicht in:

Die Verbundauthentifizierung mit SAML ist für vSphere gewohntes Terrain. Schließlich authentifizieren sich seit vSphere 5 sowohl einzelne Komponenten des vCenter als auch zahlreiche VMware-eigene Produkte und Partnerintegrationen gegenüber dem vCenter-Single-Sign-on. Mit vSphere 7 stehen nun auch die Active-Directory-Verbunddienste für die vCenter-Authentifizierung bereit. In der zweiten Folge schildern wir die notwendigen Arbeiten am vCenter und beschreiben, wie Sie ADFS für vCenter-SSO aktivieren und Berechtigungen vergeben.

Notwendige Arbeiten am vCenter
OpenID Connect arbeitet mit HTTPS-Verbindungen, daher ist es sehr wichtig, dass die beteiligten Parteien einander auch auf der Ebene der SSL-Zertifikate vertrauen. Dabei müssen die Management-Workstations der vSphere-Administratoren ohne Zertifikatsmeldungen sowohl den vCenter-Web-Client als auch die ADFS-Webseite aufrufen können und das vCenter muss der SSL-Zertifikatskette der ADFS-Bereitstellung vertrauen. Das Vertrauen in das vSphere-Zertifikat können Sie auf mehrere Weisen etablieren. Die einfachste Methode in der Active-Directory-Umgebung besteht darin, die vCenter-eigene Root CA über Gruppenrichtlinien als "vertrauenswürdige Stammzertifizierungsstelle" zu verteilen.

Das vCenter selbst vertraut von Haus aus keiner Root-CA außer der eigenen. Hier müssen Sie die Zertifikatskette, die zu Ihrem ADFS-Zertifikat führt, in den Truststore des vCenters einspielen. Die einzige Ausnahme betrifft das Szenario, wenn Ihre vCenter-CA der Unternehmens-PKI Ihrer Firma untergeordnet ist, die auch das ADFS-Zertifikat ausstellt. In diesem Fall müssen Sie nichts weiter unternehmen.

Eine solche ADFS-Bereitstellung ist aber nur für die interne Nutzung geeignet. Falls Sie eine öffentliche CA hinzufügen müssen, öffnen Sie im Web-Client das Menü "Verwaltung" und wechseln Sie dort auf "Zertifikatsverwaltung". Hier importieren Sie nun das Root-Zertifikat und die darunterliegende Zertifikatskette Ihres ADFS-Zertifikats.

Die Umleitungs-URIs haben Buttons zum Kopieren. Die Daten sind für spätere Schritte wichtig.
Bild 2: Die Umleitungs-URIs haben Buttons zum Kopieren. Die Daten sind für spätere Schritte wichtig.
 

Wechseln Sie nun im Menü "Verwaltung" zu "Single Sign-on" und wählen Sie den Unterpunkt "Konfiguration". Oben rechts finden Sie den Button "Identitätsanbieter ändern”. Klicken Sie auf das kleine Informationssymbol neben dem Button. Es öffnet sich daraufhin ein Pop-up, auf dem zwei Umleitungs-URIs angezeigt werden. Kopieren Sie beide in eine Textdatei.

vCenter-Anwendung in ADFS einrichten
Öffnen Sie nun die MMC-Konsole "ADFS Manager" und verbinden Sie diese zu Ihrer ADFS-Bereitstellung. Klicken Sie im Navigationsbaum auf "Anwendungsgruppen" und dort im Aktionsmenü auf "Anwendungsgruppe hinzufügen". Als neue Anwendungsgruppe wählen Sie "Client/ Server-Anwendungen" in der Variante "Serveranwendung mit Zugriff auf eine Web-API".

Im nächsten Schritt des Assistenten müssen Sie der Gruppe einen Namen geben. Kopieren Sie den GUID-Wert unter "Client-ID" in eine Textdatei und fügen Sie nacheinander die beiden Umleitungs-URIs aus dem vCenter ein. Im nächsten Schritt müssen Sie den Button "Gemeinsamen geheimen Schlüssel generieren" betätigen und den geheimen Schlüssel kopieren. Bei "Web-API" müssen Sie wieder einen Namen und einen Bezeichner festlegen. Fügen Sie als Bezeichner die Client-ID aus dem vorherigen Schritt ein.

Wählen Sie nun eine korrekte Zugriffssteuerungsrichtlinie für den vCenter-Zugriff aus. Der Einfachheit halber können Sie zunächst die Richtlinie "Jedem Einzelnen Zugriff gewähren" wählen und später eine passendere Richtlinie einstellen. Kreuzen Sie schließlich im Schritt "Anwendungsberechtigungen konfigurieren" die beiden Punkte "openid" und "allatclaims" an. Ersterer dürfte bereits vorbelegt sein, Zweiteren müssen Sie noch hinzufügen.

Beim Einrichten der Zugriffssteuerungsrichtlinien ist OpenID bereits vorausgewählt.
Bild 3: Beim Einrichten der Zugriffssteuerungsrichtlinien ist OpenID bereits vorausgewählt.
 

Beenden Sie den Assistenten, wählen Sie die neu erstellte Anwendungsgruppe aus und klicken Sie im Kontextmenü auf "Eigenschaften". Bearbeiten Sie den Punkt "Web-API" und fügen Sie im Reiter "Ausstellungstransformationsregeln" drei Regeln vom Typ "LDAP-Attribute als Anspruch senden" mit Attributspeicher "Active Directory" hinzu:

  • "Token-Groups - durch langen Domänennamen qualifiziert"; ausgehender Anspruchstyp = Gruppe
  • "User-Principal-Name"; ausgehender Anspruchstyp = Namens-ID
  • "User-Principal-Name"; ausgehender Anspruchstyp = UPN

Jetzt schließen Sie alle Eigenschaften-Dialoge. Zum Schluss benötigen Sie noch die OpenID-URL Ihrer ADFS-Farm. Am einfachsten erhalten Sie sie mit der Power-Shell über dieses Kommando:

Import-Module ADFS

Get-AdfsEndpoint | Select-Object -ExpandProperty FullUrl | Select-String openid-configuration

Kopieren Sie die gesamten URL in eine Textdatei.

ADFS für vCenter-SSO aktivieren
Jetzt haben Sie alle benötigten Informationen zusammen, um die Einbindung der ADFS-Authentifizierung in Ihr vCenter-SSO abzuschließen. Klicken Sie dafür im Verwaltungsmenü unter "Single Sign-on-Konfiguration" auf den Button "Identitätsanbieter ändern”. Sie sehen nun einen Assistenten, der es erlaubt, die Identitätsquelle von "Eingebettet" in "Microsoft ADFS" zu ändern. Fügen Sie in den einzelnen Schritten des Assistenten folgende Daten ein:

  • Client-ID, Shared Secret und OpenID-URL, die Sie von Ihrem ADFS-Server kopiert haben.
  • Distinguished Name (DN) der OU, in der sich potenzielle vCenter-User befinden.
  • DN der OU, in der sich Gruppen befinden, denen Sie vSphere-Rechte zuweisen.
  • Das User-Account für LDAP-Bind als UPN oder DN. Das UPN-Format ist normalerweise besser geeignet, da es unabhängig von einer Verschiebung des Users innerhalb der OU-Struktur ist.
  • Ziel-DC im Format "ldap://fqdn:port" beziehungsweise "ldaps://fqdn:port". Falls Benutzer und Gruppen aus mehreren Domains desselben Forests stammen sollen, müssen Sie den Global Catalog auf dem Port 3268 (unverschlüsselt) beziehungsweise 3269 (verschlüsselt) verwenden. Im Single-Domain-Szenario kommuniziert Ihr vCenter auf Port 389 (unverschlüsseltes LDAP) beziehungsweise 636 (LDAPS).
  • LDAPS-Zertifikate der DCs.

Nach Abschluss der Dateneingabe validiert das vCenter die neue Konfiguration und zeigt eine Übersichtsseite mit allen Daten an. Damit ist die Einrichtung abgeschlossen. Die nächste Anmeldung am vCenter-Web-Client fordert Sie zunächst nur auf, einen Benutzernamen einzugeben. Stammt er aus der lokalen SSO-Domäne (meistens "vsphere.local"), sehen Sie im nächsten Schritt die Eingabemaske für das Kennwort. Der von Ihnen eingegebene Benutzername wird weiterhin angezeigt, er ist aber nicht mehr änderbar. Nutzen Sie hingegen einen Namen aus dem Active Directory, leitet Sie das System auf die ADFS-Anmeldeseite weiter und Sie müssen sich mit Ihren AD-Anmeldedaten und gegebenenfalls einem zweiten Faktor authentifizieren. Anschließend leitet ADFS Ihren Browser zurück zum vCenter und meldet Sie am Web-Client an.

Aber Achtung: Falls Ihr Browser und die ADFS-Bereitstellung Ihrer Organisation so konfiguriert sind, dass diese Anmeldedaten der aktuellen Windows-Sitzung durchreichen, meldet ADFS Sie automatisch mit diesen Daten am vCenter an. Müssen Sie für die Arbeit am vCenter ein anderes Konto wie ein dediziertes Admin-Konto benutzen, dann müssen Sie Ihre Konfiguration eventuell anpassen oder den Browser zum Arbeiten mit dem vCenter-Web-Client im Kontext dieses Benutzers starten.

Berechtigungen vergeben
Falls Sie bereits mit Benutzern und Gruppen aus dem Active Directory in Ihrem vCenter arbeiten, behalten die vergebenen Berechtigungen auch mit ADFS Gültigkeit. Ihr vCenter ist also nach dem Abschluss des "Assistenten für die Änderung des Identitätsanbieters" sofort wieder einsatzfähig. Die Berechtigungsvergabe an AD-Gruppen und -Benutzer funktioniert ansonsten genauso wie beim eingebetteten Identitätsanbieter. Allerdings zeigt die Verzeichnisauswahl nicht die einzelnen AD-Domänen, sondern lediglich "Microsoft ADFS" an. Die Suche während der Eingabe des gewünschten Gruppen- oder Benutzernamens listet in einem Forest mit mehreren Domänen passende Sicherheitsprinzipale aus allen Domänen auf.

Obgleich der Identitätsanbieter als "Microsoft ADFS" angegeben ist, spielt Ihre ADFS-Bereitstellung bei diesem Vorgang technisch keine Rolle – die Suche nach Benutzern und Gruppen erfolgt über die eingerichtete LDAP-Anbindung.

Zum Standard-Identitätsanbieter zurückkehren
Haben Sie den Wechsel zu ADFS als Identitätsanbieter vollzogen, wird für die Active-Directory-Domänen die Verbundauthentifzierung erzwungen. Sie können den eingestellten Identitätsanbieter jedoch ohne Probleme wieder in den Standard-IdP wechseln. Dies geschieht erneut mit dem Button "Identitätsanbieter ändern" im Menü "Singe Sign-on / Konfiguration". Um diese Änderung vorzunehmen, müssen Sie als SSO-Administrator (in der Regel ist es der Account "administrator@vsphere.local") angemeldet sein.

Wählen Sie in dem sich öffnenden Dialog "Eingebettet" aus. War vor der Umstellung auf ADFS bereits Active-Directory-Authentifizierung im vCenter konfiguriert, sind alle diesbezüglichen Einstellungen inklusive der Domänen-Mitgliedschaft der vCenter-Appliance wieder aktiv. Die an AD-Benutzer und -Gruppen über den ADFS-Provider vergebenen Berechtigungen bleiben ebenfalls in Kraft.

vCenter als SAML-Authentifizierungsprovider
In den vSphere-Versionen 6.5 und 6.7 war es möglich, den SSO-Anbieter des vCenters auch für Drittanbieter-Applikationen als SAML-Provider (IdP) zu verwenden. Das haben zum Beispiel einige vRealize-Komponenten und andere VMware-Produkte mit Weboberflächen genutzt. Aber auch selbst- oder fremdentwickelte Applikationen ließen sich mit Verbundauthentifizierung über das vCenter versehen, sofern sie SAML 2.0 vollständig unterstützten. Damit ließ sich die Anzahl der Server mit Bezug zum Active Directory reduzieren oder beispielsweise auch die Smartcard-Authentifizierung für Fremdprodukte realisieren.

Diese Funktion ist mit vSphere 7 insofern entfallen, als dass es keinen Weg gibt, eine beliebige SAML-fähige Webapplikation als Service Provider in das vCenter-SSO einzutragen. Diese Funktionalität hat es in den früheren vSphere-Versionen nicht in den HTML5-Client geschafft und war bis zum Schluss dem Flash-basierten FLEX-Client vorbehalten. Dieser ist mit vCenter 7 ersatzlos weggefallen.

Ein Upgrade eines vCenter 6.7 auf 7.0 behält die SSO-Integrationen theoretisch bei. Allerdings sind die Ergebnisse in der Praxis eher gemischt und Troubleshooting- und Anpassungsmöglichkeiten sind hier recht dürftig. Daher sollten Sie Ihre SAML-Applikationen bereits vor dem Upgrade auf ADFS oder einen anderen in Ihrer Umgebung implementierten Identity Provider umstellen, um langfristig einen störungsfreien Betrieb dieser Systeme zu gewährleisten.

Fazit
Um die Anmeldung am vCenter-Web-Client mit MFA oder standortabhängigen Policies abzusichern, bietet Ihnen vSphere 7 die Möglichkeit, Microsoft ADFS als Identity Provider anzubinden. Die Prozedur ist einfach und lässt sich bei Bedarf auch ohne Disruption zurückrollen. Vorsicht ist jedoch geboten, wenn Sie in einer früheren vCenter-Version das vCenter-SSO als Identity Provider verwendet haben und nun auf vSphere 7 migrieren.

jp/ln/Evgenij Smirnov

Im ersten Teil der Workshop-Serie erklärten wir die Grundlagen der Authentifizierung mittels ADFS und haben gezeigt, wie Sie die ADFS-Infrastruktur planen und das Active Directory vorbereiten.

Ähnliche Beiträge

Moderne vCenter-Anmeldung mit ADFS (1)

Die Verbundauthentifizierung mit SAML ist für vSphere gewohntes Terrain. Schließlich authentifizieren sich seit vSphere 5 sowohl einzelne Komponenten des vCenter als auch zahlreiche VMware-eigene Produkte und Partnerintegrationen gegenüber dem vCenter-Single-Sign-on. Mit vSphere 7 stehen nun auch die Active-Directory-Verbunddienste für die vCenter-Authentifizierung bereit.

Azure mit lokalen Netzen verbinden (3)

Azure bietet vielfältige Möglichkeiten, um Ressourcen in der Cloud mit lokalen Netzwerken zu verbinden. Dazu gehören auch Sicherheitsmechanismen und Loadbalancer, die den Datenverkehr zwischen Cloud und lokalem Rechenzentrum nicht nur zur Verfügung stellen, sondern absichern und hochverfügbar konfigurieren. IT-Administrator zeigt die Wege auf, um die Cloudumgebung mit dem lokalen Netzwerk zu verbinden. Im dritten und letzten Teil der Workshopserie zeigen wir, wie Sie virtuelle Firewalls hochziehen.

Azure mit lokalen Netzen verbinden (2)

Azure bietet vielfältige Möglichkeiten, um Ressourcen in der Cloud mit lokalen Netzwerken zu verbinden. Dazu gehören auch Sicherheitsmechanismen und Loadbalancer, die den Datenverkehr zwischen Cloud und lokalem Rechenzentrum nicht nur zur Verfügung stellen, sondern absichern und hochverfügbar konfigurieren. IT-Administrator zeigt die Wege auf, um die Cloudumgebung mit dem lokalen Netzwerk zu verbinden. Im zweiten Teil binden wir den Connection Broker an und erklären, was es mit dem Cloud Witness auf sich hat.