vCenter Server-Identitätsanbieterverbund

Ab vSphere 7.0 unterstützt vCenter Server die Verbundauthentifizierung für die Anmeldung bei vCenter Server.

Um Verbundauthentifizierung für vCenter Server zu aktivieren, konfigurieren Sie eine Verbindung mit einem externen Identitätsanbieter. Die von Ihnen konfigurierte Identitätsanbieterinstanz ersetzt vCenter Server als Identitätsanbieter. Derzeit unterstützt vCenter Server Active Directory Federation Services (AD FS), Okta, Microsoft Entra ID (ehemals Azure AD) und PingFederate als externe Identitätsanbieter. vCenter Server unterstützt AD FS in vSphere 7.0 und höher, Okta in vSphere 8.0 Update 1 und höher, Microsoft Entra ID in vSphere 8.0 Update 2 und höher sowie PingFederate ab vSphere 8.0 Update 3.

Hinweis: VMware empfiehlt Ihnen, Verbundauthentifizierung zu verwenden, da in vSphere künftig tokenbasierte Authentifizierung verwendet wird. vCenter Server verwendet weiterhin lokale Konten für Administratorzugriff und Fehlerbehebung.

Funktionsweise des vCenter Server-Identitätsanbieterverbunds

Mit dem vCenter Server-Identitätsanbieterverbund können Sie einen externen Identitätsanbieter für Verbundauthentifizierung konfigurieren. In dieser Konfiguration interagiert der externe Identitätsanbieter im Auftrag von vCenter Server mit der Identitätsquelle.

Grundlegendes zum vCenter Server-Identitätsanbieterverbund

In vSphere 7.0 und höher unterstützt vCenter Server die Verbundauthentifizierung. Wenn sich in diesem Szenario ein Benutzer bei vCenter Server anmeldet, leitet vCenter Server die Benutzeranmeldung an den externen Identitätsanbieter weiter. Die Benutzeranmeldedaten werden vCenter Server nicht mehr direkt bereitgestellt. Stattdessen werden dem externen Identitätsanbieter die Anmeldedaten vom Benutzer zur Verfügung gestellt. vCenter Server stuft den externen Identitätsanbieter als vertrauenswürdig für die Durchführung der Authentifizierung ein. Im Verbundmodell werden Anmeldedaten niemals direkt vom Benutzer an einen Dienst oder eine Anwendung, sondern ausschließlich an den Identitätsanbieter übergeben. Folglich können Ihre Anwendungen und Dienste, wie z. B. vCenter Server, einen Verbund mit dem Identitätsanbieter eingehen.

vCenter Server-Unterstützung für externe Identitätsanbieter

vCenter Server unterstützt die folgenden externen Identitätsanbieter:

• AD FS (vSphere 7.0 und höher)
• Okta (vSphere 8.0 Update 1 und höher)
• Microsoft Entra ID, vormals Azure AD (vSphere 8.0 Update 2 und höher)
• PingFederate (ab vSphere 8.0 Update 3)

Vorteile des vCenter Server-Identitätsanbieterverbunds

Der vCenter Server-Identitätsanbieterverbund bietet die folgenden Vorteile.

• Sie können Single Sign-On mit der vorhandenen Verbundinfrastruktur und vorhandenen Anwendungen verwenden.
• Sie können die Sicherheit des Datencenters verbessern, da die Benutzeranmeldedaten niemals von vCenter Server verarbeitet werden.
• Sie können die Authentifizierungsmechanismen (wie z. B. Multifaktor-Authentifizierung) verwenden, die vom externen Identitätsanbieter unterstützt werden.

Architektur des vCenter Server-Identitätsanbieterverbunds

Zum Einrichten einer Vertrauensstellung der vertrauenden Seite zwischen vCenter Server und einem externen Identitätsanbieter müssen Sie Identifizierungsinformationen und einen gemeinsamen geheimen Schlüssel zwischen ihnen festlegen. vCenter Server verwendet das OpenID Connect-Protokoll (OIDC), um ein Identitätstoken zu erhalten, das den Benutzer bei vCenter Server authentifiziert.

Zu den allgemeinen Schritten zum Konfigurieren eines externen Identitätsanbieters mit vCenter Server gehören:

1. Einrichten einer Vertrauensstellung der vertrauenden Partei zwischen vCenter Server und dem externen Identitätsanbieter durch Erstellen einer OIDC-Konfiguration. Für AD FS erstellen Sie eine Anwendungsgruppe oder Anwendung. Für Okta, Microsoft Entra ID und PingFederate erstellen Sie eine native Anwendung mit OpenID Connect als Anmeldemethode. Die OIDC-Konfiguration besteht aus einer Serveranwendung und einer Web-API. Die beiden Komponenten enthalten die Informationen, die von vCenter Server zum Herstellen von Vertrauen und zur Kommunikation mit dem externen Identitätsanbieter verwendet werden.
2. Erstellen eines entsprechenden Identitätsanbieters in vCenter Server.
3. Konfigurieren von Gruppenmitgliedschaften in vCenter Server, um Anmeldungen von Benutzern in der Domäne des externen Identitätsanbieters zu autorisieren.

Der Identitätsanbieter-Administrator muss die folgenden Informationen bereitstellen, um die Konfiguration des vCenter Server-Identitätsanbieters zu erstellen:

• Clientbezeichner: Die UUID-Zeichenfolge, die in AD FS beim Erstellen der Anwendungsgruppe (oder Anwendung) generiert wird und die die Anwendungsgruppe (oder Anwendung) identifiziert, bzw. die in Okta, Microsoft Entra ID oder PingFederate generiert wird, wenn Sie die OpenID Connect-Anwendung erstellen.
• Gemeinsamer geheimer Schlüssel: Der geheime Schlüssel, der in AD FS generiert wird, wenn Sie die Anwendungsgruppe (oder Anwendung) erstellen, bzw. der in Okta, Microsoft Entra ID oder PingFederate generiert wird, wenn Sie die OpenID Connect-Anwendung erstellen. Der Schlüssel wird zur Authentifizierung vCenter Server beim externen Identitätsanbieter verwendet.
• OpenID-Adresse: Die OpenID Provider Discovery-Endpoint-URL des Servers des externen Identitätsanbieters, die eine bekannte Adresse angibt,. Dabei handelt es sich in der Regel um den mit dem Pfad „/.well-known/openid-configuration“ verketteten Aussteller-Endpoint. Dies ist ein Beispiel für eine OpenID-Adresse für eine AD FS-Konfiguration:

  https://webserver.example.com/adfs/.well-known/openid-configuration

  Dies ist ein Beispiel für eine OpenID-Adresse für eine Okta-Konfiguration:

  https://example.okta.com/oauth2/default/.well-known/openid-configuration

  Beispiel für eine OpenID-Adresse für eine Microsoft Entra ID-Konfiguration:

  https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/v2.0/.well-known/openid-configuration

  Beispiel für eine OpenID-Adresse für eine PingFederate-Konfiguration:

  https://pingfederate-fqdn-and-port/.well-known/openid-configuration

VMware Identity Services und Verbundauthentifizierung

In vSphere 8.0 Update 1 und höher ermöglicht VMware Identity Services die Integration mit externen Identitätsanbietern als Verbundidentitätsanbieter. VMware Identity Services ist eine Art „abgespeckte“ Version von VMware Workspace ONE, die in vSphere integriert ist.

Wenn Sie vSphere 8.0 Update 1 oder höher installieren oder ein Upgrade darauf durchführen, wird VMware Identity Services standardmäßig auf vCenter Server aktiviert. Wenn Sie Okta, Microsoft Entra ID oder PingFederate als externen Identitätsanbieter konfigurieren, verwendet vCenter Server VMware Identity Services für die Kommunikation mit Ihrem Okta-, Microsoft Entra ID- oder PingFederate-Server.

vCenter Server unterstützt Okta, Microsoft Entra ID und PingFederate als externe Identitätsanbieter in einer Konfiguration im erweiterten verknüpften Modus. Obwohl in einer Konfiguration im erweiterten verknüpften Modus mehrere vCenter Server-Systeme VMware Identity Services ausführen, kommunizieren nur ein einziger vCenter Server und dessen VMware Identity Services mit Ihrem externen Identitätsanbieter-Server. Wenn Sie beispielsweise über eine Konfiguration im erweiterten verknüpften Modus mit drei vCenter Server-Systemen (A, B und C) verfügen und den externen Okta-Identitätsanbieter auf vCenter Server A konfigurieren, ist vCenter Server A das einzige System, das sämtliche Okta-Anmeldungen verarbeitet. vCenter Server B und vCenter Server C kommunizieren nicht direkt mit dem Okta-Server. Informationen zum Konfigurieren von VMware Identity Services auf einem anderen vCenter Server in der ELM-Konfiguration für die Interaktion mit Ihrem externen IDP-Server finden Sie unter Aktivierungsvorgang für externe Identitätsanbieter in Konfigurationen des erweiterten verknüpften Modus.

Hinweis: Wenn Sie Okta als externen Identitätsanbieter konfigurieren, müssen alle vCenter Server-Systeme in einer Konfiguration des erweiterten verknüpften Modus mindestens vSphere 8.0 Update 1 ausführen. Für Microsoft Entra ID ist mindestens vSphere 8.0 Update 2 erforderlich. Für PingFederate ist mindestens vSphere 8.0 Update 3 erforderlich.

Warnung: Wenn Sie eine Konfiguration im erweiterten verknüpften Modus mit Okta, Microsoft Entra ID oder PingFederate verwenden, können Sie den vCenter Server, der die VMware Identity Services ausführt und mit dem Identitätsanbieter kommuniziert, nicht aus der ELM-Konfiguration entfernen.

Authentifizierungsprozess für VMware Identity Services

Wenn Sie vCenter Server für die Verwendung von VMware Identity Services zur Kommunikation mit Ihrem Identitätsanbieter konfigurieren, erfolgt der folgende Authentifizierungsvorgang:

1. Ein Benutzer meldet sich mit vCenter Server beim vSphere Client an.
2. vCenter Single Sign On delegiert die Benutzerauthentifizierung und leitet die Benutzeranforderung an VMware Identity Services weiter.
3. Der VMware Identity Services-Prozess fordert ein Token vom externen Identitätsanbieter an, um die Benutzersitzung einzurichten.
4. Der externe Identitätsanbieter authentifiziert den Benutzer (er kann MFA- oder SSO-Anmeldedaten verwenden) und gibt das Token an VMware Identity Services zurück.

   Das Token enthält die Benutzerbeanspruchungen.

5. Der VMware Identity Services-Prozess validiert das Identitätsanbieter-Token, generiert ein entsprechendes VMware Identity Services-Token und sendet das VMware Identity Services-Token an vCenter Single Sign On.
6. vCenter Single Sign On validiert das Token und genehmigt die Anmeldeanforderung.

Hinweis: AD FS verwendet für die Verbundauthentifizierung keine VMware Identity Services.

Verfahren zur Interaktion von vCenter Server mit Benutzern und Gruppen, die von SCIM übertragen werden

Wenn Sie Ihren externen Identitätsanbieter konfigurieren, verwendet vCenter Server das System für domänenübergreifende Identitätsverwaltung (SCIM) für die Benutzer- und Gruppenverwaltung. SCIM ist ein offener Standard für die Automatisierung des Austauschs von Benutzeridentitätsinformationen. Eine SCIM-Anwendung, die Sie auf Ihrem Server für externe IDPs erstellen, verwaltet die Benutzer und Gruppen für den externen Identitätsanbieter, die Sie an vCenter Server weitergeben möchten. vCenter Server verwendet SCIM auch bei der Suche nach Benutzern und Gruppen, um vCenter Server-Objekten Berechtigungen zuzuweisen.

Hinweis: Eine AD FS-Konfiguration durchsucht Active Directory mithilfe von LDAP. SCIM wird nicht verwendet.

Komponenten des vCenter Server-Identitätsanbieterverbunds

Die folgenden Komponenten umfassen eine Konfiguration des vCenter Server-Identitätsanbieterverbunds:

• Einem vCenter Server
  • Für AD FS: vCenter Server 7.0 oder höher
  • Für Okta: vCenter Server 8.0 Update 1 oder höher
  • Für Microsoft Entra ID: vCenter Server 8.0 Update 2 oder höher
  • Für PingFederate: vCenter Server 8.0 Update 3
• Einem auf dem vCenter Server konfigurierten Identitätsanbieterdienst
• Ein externer Identitätsanbieter (AD FS, Okta, Microsoft Entra ID oder PingFederate)
• Eine OIDC-Konfiguration (OpenID Connect):
  • Für AD FS: Eine Anwendungsgruppe (auch als „Anwendung“ bezeichnet)
  • Für Okta, Microsoft Entra ID oder PingFederate: Eine OpenID Connect-Anwendung
• Eine System for Cross-domain Identity Management (SCIM)-Anwendung für die Verwaltung von Benutzern und Gruppen (nur für Okta, Microsoft Entra ID oder PingFederate)
• Gruppen und Benutzer externer Identitätsanbieter, die vCenter Server-Gruppen und -Benutzern zugeordnet sind
• VMware Identity Services, die auf vCenter Server aktiviert sind (nur für Okta, Microsoft Entra ID oder PingFederate)
• Für PingFederate optional das SSL-Zertifikat oder die Zertifikatskette des PingFederate-Servers, sofern dieses Zertifikat nicht von einer bekannten, öffentlichen Zertifizierungsstelle ausgestellt wurde. Das PingFederate-SSL-Zertifikat importieren Sie in vCenter Server.

Einschränkungen und Interoperabilität des vCenter Server-Identitätsanbieterverbunds

Der vCenter Server-Identitätsanbieterverbund kann mit vielen anderen VMware-Funktionen zusammenarbeiten.

Beachten Sie beim Planen Ihrer Strategie für den vCenter Server-Identitätsanbieterverbund mögliche Beschränkungen bei der Interoperabilität.

Authentifizierungsmechanismen

In einer Konfiguration für vCenter Server-Identitätsanbieterverbund verarbeitet der externe Identitätsanbieter die Authentifizierungsmechanismen (Kennwörter, MFA, Biometrie usw.).

AD FS und Unterstützung für eine einzelne Active Directory-Domäne

Wenn Sie den Identitätsanbieterverbund von vCenter Server für AD FS konfigurieren, werden Sie vom Assistenten „Hauptidentitätsanbieter konfigurieren“ aufgefordert, LDAP-Informationen für die einzige AD-Domäne einzugeben, welche die Benutzer und Gruppen enthält, die auf vCenter Server zugreifen sollen. vCenter Server leitet die AD-Domäne, die zur Autorisierung und für Berechtigungen verwendet wird, vom Benutzer-Basis-DN ab, den Sie im Assistenten angeben. Sie können Berechtigungen für vSphere-Objekte nur für Benutzer und Gruppen aus dieser AD-Domäne hinzufügen. Benutzer oder Gruppen aus untergeordneten AD-Domänen oder anderen Domänen in der AD-Gesamtstruktur werden vom vCenter Server-Identitätsanbieterverbund nicht unterstützt.

Unterstützung von Okta, Microsoft Entra ID und PingFederate für mehrere Domänen

Wenn Sie den Identitätsanbieterverbund von vCenter Server für Okta, Microsoft Entra ID oder PingFederate konfigurieren, werden Sie vom Assistenten „Hauptidentitätsanbieter konfigurieren“ aufgefordert, LDAP-Informationen für die verschiedenen Domänen einzugeben, welche die Benutzer und Gruppen enthalten, die auf vCenter Server zugreifen sollen.

Kennwort-, Sperr- und Token-Richtlinien

Wenn vCenter Server als Identitätsanbieter fungiert, steuern Sie Kennwort-, Sperr- und Tokenrichtlinien von vCenter Server für die Standarddomäne (vsphere.local oder den Domänennamen, den Sie bei der Installation von vSphere eingegeben haben). Wenn Sie die Verbundauthentifizierung mit vCenter Server verwenden, steuert der externe Identitätsanbieter die Kennwort-, Sperrungs- und Token-Richtlinien für die in der Identitätsquelle gespeicherten Konten, wie z. B. Active Directory.

Audits und Konformität

Wenn Sie vCenter Server-Identitätsanbieterverbund verwenden, erstellt vCenter Server weiterhin Protokolleinträge für erfolgreiche Benutzeranmeldungen. Der externe Identitätsanbieter ist jedoch für die Verfolgung und Protokollierung von Aktionen wie fehlgeschlagenen Versuchen zur Kennworteingabe und die Sperrung von Benutzerkonten verantwortlich. vCenter Server protokolliert solche Ereignisse nicht, da sie für vCenter Server nicht mehr sichtbar sind. Wenn beispielsweise AD FS der Identitätsanbieter ist, werden Fehler für Verbundanmeldungen von AD FS nachverfolgt und protokolliert. Wenn vCenter Server der Identifizierungsanbieter für lokale Anmeldungen ist, werden Fehler für lokale Anmeldungen von vCenter Server nachverfolgt und protokolliert. In einer Verbundkonfiguration protokolliert vCenter Server weiterhin Benutzeraktionen nach der Anmeldung.

Integration vorhandener VMware-Produkte in externe Identitätsanbieter

VMware-Produkte, die in vCenter Server integriert sind (z. B. VMware Aria Operations, vSAN, NSX usw.), funktionieren weiterhin wie bisher.

Produkte, die nach der Anmeldung integriert werden

Produkte, die nach der Anmeldung integriert werden (also keine separate Anmeldung benötigten), funktionieren weiterhin wie bisher.

Einfache Authentifizierung für API-, SDK- und CLI-Zugriff

Vorhandene Skripts, Produkte und andere Funktionen, die auf API-, SDK- oder CLI-Befehlen basieren, die eine einfache Authentifizierung (Benutzername und Kennwort) verwenden, funktionieren weiterhin wie zuvor. Intern erfolgt die Authentifizierung durch Übergabe des Benutzernamens und des Kennworts. Diese Weitergabe des Benutzernamens und des Kennworts beeinträchtigt einige der Vorteile der Verwendung des Identitätsverbunds, da das Kennwort für vCenter Server und Ihre Skripts verfügbar gemacht werden. Migrieren Sie nach Möglichkeit zu einer token-basierten Authentifizierung.

Zugriff auf die vCenter Server-Verwaltungsschnittstelle

Wenn der Benutzer ein Mitglied der Administratorgruppe von vCenter Server ist, wird der Zugriff auf die vCenter Server-Verwaltungsschnittstelle (früher als vCenter Server Appliance-Verwaltungsschnittstelle oder VAMI bezeichnet) unterstützt.

Eingeben von Benutzernamentext auf der AD FS-Anmeldeseite

Die AD FS-Anmeldeseite unterstützt keine Übergabe von Text, um das Textfeld „Benutzername“ vorab auszufüllen. Infolgedessen müssen Sie bei Verbundanmeldungen mit AD FS nach der Eingabe Ihres Benutzernamens auf der vCenter Server-Startseite und der Umleitung auf die AD FS-Anmeldeseite Ihren Benutzernamen auf der AD FS-Anmeldeseite erneut eingeben. Der Benutzername, den Sie auf der vCenter Server-Startseite eingeben, wird benötigt, um die Anmeldung an den entsprechenden Identitätsanbieter umzuleiten, und der Benutzername auf der AD FS-Anmeldeseite ist für die Authentifizierung bei AD FS erforderlich. Diese Unfähigkeit, den Benutzernamen an die AD FS-Anmeldeseite zu übergeben, ist eine Einschränkung von AD FS. Sie können dieses Verhalten nicht direkt über vCenter Server konfigurieren oder ändern.

Unterstützung für IPv6-Adressen

AD FS, Microsoft Entra ID und PingFederate unterstützen IPv6-Adressen. Okta unterstützt keine IPv6-Adressen.

Konfiguration einer einzelnen Instanz von VMware Identity Services

Wenn Sie vSphere 8.0 Update 1 oder höher installieren oder ein Upgrade darauf durchführen, sind standardmäßig VMware Identity Services auf vCenter Server aktiviert. Wenn Sie Okta, Microsoft Entra ID oder PingFederate in einer Konfiguration des erweiterten verknüpften Modus konfigurieren, verwenden Sie VMware Identity Services auf einem einzelnen vCenter Server-System. Wenn Sie Okta zum Beispiel in einer Konfiguration des erweiterten verknüpften Modus verwenden, die aus drei vCenter Server-Systemen besteht, wird nur ein vCenter Server und die zugehörige Instanz von VMware Identity Services für die Kommunikation mit dem Okta-Server verwendet.

Warnung:

Wenn in einer ELM-Konfiguration, die VMware Identity Services verwendet, das mit dem externen Identitätsanbieter kommunizierende vCenter Server-System nicht mehr verfügbar ist, können Sie VMware Identity Services auf anderen vCenter Server-Instanzen in der ELM-Konfiguration konfigurieren, um mit Ihrem externen IDP-Server zu interagieren. Weitere Informationen hierzu finden Sie unter Aktivierungsvorgang für externe Identitätsanbieter in Konfigurationen des erweiterten verknüpften Modus.

Neukonfigurieren des primären Netzwerkbezeichners

Zum Neukonfigurieren des primären Netzwerkbezeichners (PNID) von vCenter Server müssen Sie die Konfiguration des externen Identitätsanbieters wie folgt aktualisieren.

• AD FS: Fügen Sie dem AD FS-Server die neuen Umleitungs-URIs hinzu.
• Okta: Konfigurieren Sie Okta neu. Lesen Sie die Informationen unter Konfigurieren des vCenter Server-Identitätsanbieterverbunds für Okta durch und befolgen Sie die Schritte zum Erstellen des Identitätsanbieters auf vCenter Server.
• Microsoft Entra ID: Konfigurieren Sie Entra ID neu. Lesen Sie die Informationen unter Konfigurieren des vCenter Server-Identitätsanbieterverbunds für Microsoft Entra ID durch und befolgen Sie die Schritte zum Erstellen des Identitätsanbieters auf vCenter Server.
• PingFederate: Konfigurieren Sie PingFederate neu. Lesen Sie die Informationen unter Konfigurieren des vCenter Server-Identitätsanbieterverbunds für PingFederate durch und befolgen Sie die Schritte zum Erstellen des Identitätsanbieters auf vCenter Server.

vCenter Server-Identitätsanbieterverbund-Lebenszyklus

Bei der Verwaltung des Lebenszyklus des vCenter Server-Identitätsanbieterverbunds gelten einige besondere Überlegungen.

Sie können den Lebenszyklus Ihres vCenter Server-Identitätsanbieterverbunds auf folgende Arten verwalten.

Migrieren von der Verwendung von Active Directory zu einem externen Identitätsanbieter

Wenn Sie Active Directory als Identitätsquelle für vCenter Server verwenden, ist die Migration zur Verwendung eines externen Identitätsanbieters einfach. Wenn Ihre Active Directory-Gruppen und -Rollen mit Ihren Identitätsanbieter-Gruppen und -Rollen übereinstimmen, müssen Sie keine zusätzlichen Maßnahmen ergreifen. Wenn die Gruppen und Rollen nicht übereinstimmen, müssen Sie zusätzliche Aufgaben durchführen. Wenn der vCenter Server ein Domänenmitglied ist, sollten Sie ihn aus der Domäne entfernen, da er für den Identitätsverbund nicht benötigt oder verwendet wird.

Domänenübergreifendes Neuverweisen und Migration

Der vCenter Server-Identitätsanbieterverbund unterstützt die domänenübergreifende Neuverweisung, das heißt, das Verschieben eines vCenter Server von einer vSphere SSO-Domäne in eine andere. Der neu verwiesene vCenter Server erhält die replizierte Identitätsanbieter-Konfiguration vom vCenter Server-System oder von den Systemen, auf die er zuvor verwies.

Im Allgemeinen müssen Sie keine zusätzliche Identitätsanbieter-Neukonfiguration für eine domänenübergreifende Neuverweisung durchführen, es sei denn, eine der folgenden Bedingungen ist erfüllt.

1. Die Identitätsanbieter-Konfiguration des neu verwiesenen vCenter Servers unterscheidet sich von der Identitätsanbieter-Konfiguration des vCenter Servers, auf den zuvor verwiesen wurde.
2. Dies ist das erste Mal, dass der neu verwiesene vCenter Server eine Identitätsanbieter-Konfiguration erhält.

In diesen Fällen sind einige zusätzliche Arbeiten erforderlich. Für AD FS beispielsweise müssen Sie die Umleitungs-URIs des vCenter Server-Systems zur entsprechenden Anwendungsgruppe auf dem AD FS-Server hinzufügen. Wenn beispielsweise vCenter Server 1 mit AD FS-Anwendungsgruppe A (oder ohne AD FS-Konfiguration) neu auf vCenter Server 2 mit AD FS-Anwendungsgruppe B verwiesen wird, müssen Sie die Umleitungs-URIs von vCenter Server 1 zu Anwendungsgruppe B hinzufügen.

Benutzer- und Gruppensynchronisierung und vCenter Server-Sicherung und -Wiederherstellung

Je nachdem, wann Sie Ihre Benutzer und Gruppen mit vCenter Server synchronisieren und wann Sie Ihre vCenter Server sichern, müssen Sie, wenn Sie Ihre vCenter Server wiederherstellen müssen, möglicherweise Ihre Benutzer und Gruppen, die von SCIM übertragen wurden, erneut synchronisieren.

Um einen gelöschten Benutzer oder eine gelöschte Gruppe wiederherzustellen, können Sie den Benutzer oder die Gruppe nicht einfach vom externen Identitätsanbieter zum vCenter Server verschieben. Sie müssen die SCIM 2.0-Anwendung auf dem externen Identitätsanbieter mit dem fehlenden Benutzer oder der fehlenden Gruppe aktualisieren. Weitere Informationen hierzu finden Sie unter Wiederherstellen gelöschter SCIM-Benutzer und -Gruppen.