Auswirkungen der Konsolidierung von Nutzerkonten auf die Föderation analysieren

Wenn Sie Cloud Identity oder die G Suite mit einem externen Identitätsanbieter (Identity Provider, IdP) verbinden möchten, aber vorhandene Privatnutzerkonten konsolidieren müssen, erfahren Sie in diesem Dokument mehr über das Zusammenspiel zwischen Föderation und Konsolidierung. Außerdem wird beschrieben, wie Sie die Föderation so konfigurieren, dass Ihre Fähigkeit, vorhandene Privatnutzerkonten zu konsolidieren, nicht beeinträchtigt wird.

Zusammenspiel von Föderation und Konsolidierung von Nutzerkonten

In einer föderierten Einrichtung verbinden Sie Cloud Identity oder die G Suite mit einer externen autoritativen Quelle, sodass sie automatisch Nutzerkonten in Cloud Identity oder der G Suite bereitstellen kann.

Diese Invarianten gelten normalerweise für eine föderierte Einrichtung:

  1. Die autoritative Quelle ist die einzige Quelle für Identitäten.
  2. In Cloud Identity oder in der G Suite gibt es nur die Nutzerkonten, die von der autoritativen Quelle bereitgestellt wurden.
  3. Der SAML-Identitätsanbieter lässt die Einmalanmeldung (SSO) von Google nur für Identitäten zu, für die von der autoritativen Quelle Nutzerkonten bereitgestellt wurden.

Obwohl diese Invarianten den Best Practices für die Föderation von Google Cloud mit einem externen Identitätsanbieter entsprechen, verursachen sie Probleme bei der Migration vorhandener Privatnutzerkonten:

  1. Bestehende Privatnutzerkonten stammen nicht aus der autoritativen Quelle. Diese Konten sind bereits vorhanden und müssen nun mit einer Identität verknüpft werden, die der autoritativen Quelle bekannt ist.
  2. Bestehende Privatnutzerkonten sind nach der Migration zu Cloud Identity oder der G Suite Nutzerkonten, die nicht von der autoritativen Quelle bereitgestellt wurden. Die autoritative Quelle muss diese migrierten Konten erkennen und "übernehmen".
  3. Die Identitäten vorhandener Privatnutzerkonten sind dem SAML-Identitätsanbieter möglicherweise nicht bekannt. Trotzdem müssen sie berechtigt sein, die Einmalanmeldung zu verwenden.

Damit vorhandene Privatnutzerkonten konsolidiert werden können, müssen Sie die Föderation vorübergehend so einrichten, dass sie für die Kontokonsolidierung sicher ist.

Föderation für die Kontokonsolidierung sichern

In der folgenden Tabelle sehen Sie die Anforderungen, die zu beachten sind, wenn Sie die Föderation für die Kontokonsolidierung sichern. Wenn Sie einen externen IdP verwenden möchten, aber vorhandene Privatnutzerkonten konsolidieren müssen, ist es erforderlich, dass Ihre Einrichtung diese Anforderungen von Anfang an erfüllt. Nach der Migration vorhandener Privatnutzerkonten können Sie die Konfiguration ändern, da die Anforderungen dann nicht mehr gelten.

Anforderung Begründung
Einmalanmeldung für Identitäten mit Privatnutzerkonten zulassen Für die Migration eines Privatnutzerkontos ist eine Kontoübertragung erforderlich. Diese wird von einem Cloud Identity- oder G Suite-Administrator initiiert. Damit die Übertragung abgeschlossen werden kann, muss der Inhaber des Privatnutzerkontos jedoch der Übertragung zustimmen. Als Administrator haben Sie nur eingeschränkte Kontrolle darüber, wann die Zustimmung ausgedrückt wird und wann die Übertragung erfolgt.

Sobald der Inhaber seine Zustimmung erteilt hat und die Übertragung abgeschlossen ist, wird für alle nachfolgenden Anmeldungen die Einmalanmeldung über Ihren externen IdP durchgeführt.

Damit die Einmalanmeldung unabhängig vom Abschluss der Übertragung funktioniert, muss sie von Ihrem externen IdP für die Identitäten aller Privatnutzerkonten zugelassen werden, die Sie migrieren möchten.

Automatische Nutzerverwaltung für Identitäten mit Privatnutzerkonten verhindern Wenn Sie ein Nutzerkonto für eine Identität bereitstellen, die bereits ein Privatnutzerkonto hat, erstellen Sie ein in Konflikt stehendes Konto. Dieses verhindert, dass Sie die Inhaberschaft des Privatnutzerkontos, seine Konfiguration und alle damit verbundenen Daten an Cloud Identity oder die G Suite übertragen.

Zum Standardverhalten vieler externer IdPs gehört die proaktive Erstellung von Nutzerkonten in Cloud Identity oder der G Suite. Dieses Verhalten kann versehentlich dazu führen, dass in Konflikt stehende Konten erstellt werden.

Wenn Sie die automatische Nutzerverwaltung für Identitäten mit bestehenden Privatnutzerkonten verhindern, werden keine in Konflikt stehenden Konten versehentlich erstellt und Privatnutzerkonten werden korrekt übertragen.

Wenn Sie Privatnutzerkonten ohne übereinstimmende Identität beim externen IdP identifiziert haben, die Sie als legitim erachten und zu Cloud Identity oder zur G Suite migrieren möchten, müssen Sie darauf achten, dass Ihre Möglichkeit zur Migration dieser Privatnutzerkonten nicht durch Ihre Föderationskonfiguration beeinträchtigt wird.

Anforderung Begründung
Löschen migrierter Konten ohne übereinstimmende Identität beim externen IdP verhindern Wenn Sie ein Nutzerkonto in Cloud Identity oder in der G Suite ohne übereinstimmende Identität beim IdP haben, kann dieser das Nutzerkonto als verwaist betrachten und es sperren oder löschen.

Wenn Sie Ihren externen IdP daran hindern, migrierte Konten ohne internen Abgleich zu sperren oder zu löschen, vermeiden Sie den Verlust der mit den betroffenen Konten verbundenen Konfigurationen und Daten. Außerdem wird gewährleistet, dass Sie Konten manuell abgleichen können.

Azure AD-Föderation für die Kontokonsolidierung sichern

Wenn Sie eine Föderation von Cloud Identity oder der G Suite mit Azure AD vornehmen möchten, können Sie die G Suite Gallery-Anwendung verwenden.

Wenn Sie die Nutzerverwaltung aktivieren, ignoriert Azure AD vorhandene Konten in Cloud Identity oder in der G Suite, die kein Gegenstück in Azure AD haben. So wird die Anforderung erfüllt, dass das Löschen migrierter Konten ohne übereinstimmende Identität beim externen IdP verhindert werden muss.

Je nachdem, wie Sie die Gallery-Anwendung konfigurieren, müssen Sie weiterhin Folgendes gewährleisten:

Es gibt mehrere Möglichkeiten, diese Anforderungen zu erfüllen. Jede Methode hat Vor- und Nachteile.

Methode 1: Nutzerverwaltung nicht konfigurieren

Bei dieser Methode konfigurieren Sie die Gallery-Anwendung für die Verarbeitung der Einmalanmeldung, konfigurieren aber nicht die automatische Nutzerverwaltung. Wenn Sie die Nutzerverwaltung nicht konfigurieren, verhindern Sie die automatische Nutzerverwaltung für Identitäten mit Privatnutzerkonten.

Wenn Sie die Einmalanmeldung für Identitäten mit Privatnutzerkonten zulassen möchten, weisen Sie der Anwendung alle Identitäten zu, die möglicherweise letztendlich Zugriff auf Google-Dienste benötigen. Dies gilt auch, wenn ihre bestehenden Privatnutzerkonten noch migriert werden müssen.

Für einen Nutzer mit einem vorhandenen Privatnutzerkonto wird das entsprechende Cloud Identity- oder G Suite-Nutzerkonto automatisch erstellt, wenn die Übertragungsanfrage angenommen wird. Dieser Nutzer kann die Einmalanmeldung sofort verwenden.

Nutzer, die kein Nutzerkonto in Cloud Identity oder der G Suite haben, müssen manuell eines erstellen.

Obwohl bei dieser Methode die Anforderungen erfüllt werden und die Einrichtung am einfachsten ist, wird zwar das Risiko vermieden, besteht aber die Einschränkung, dass in Azure AD durchgeführte Attributänderungen oder Nutzersperrungen nicht an Cloud Identity oder die G Suite weitergegeben werden.

Methode 2: Zwei Anwendungen mit manueller Zuweisung

Bei dieser Methode umgehen Sie die Einschränkung, Konten in der G Suite oder Cloud Identity für Nutzer erstellen zu müssen, die kein vorhandenes Konto haben. Die Idee ist, zwei Gallery-Anwendungen zu verwenden, eine für die Nutzerverwaltung und eine für die Einmalanmeldung:

  • Die erste Anwendung wird ausschließlich für die Nutzer- und Gruppenverwaltung verwendet, wobei die Einmalanmeldung deaktiviert ist. Durch die Zuweisung von Nutzern an diese Anwendung steuern Sie, welche Konten für Cloud Identity oder die G Suite bereitgestellt werden.
  • Die zweite Anwendung wird ausschließlich für die Einmalanmeldung verwendet und ist nicht dazu autorisiert, Nutzer bereitzustellen. Indem Sie dieser Anwendung Nutzer zuweisen, steuern Sie, welche Nutzer sich anmelden dürfen.

Beim Verwenden beider Anwendungen können Sie Nutzer so zuweisen:

Methode 3: Zwei Anwendungen mit deaktivierter Nutzererstellung

Beim Konfigurieren der Nutzerverwaltung müssen Sie Azure AD autorisieren, über ein Cloud Identity- oder G Suite-Konto auf Cloud Identity oder die G Suite zuzugreifen. Normalerweise ist es am besten, zu diesem Zweck ein spezielles Super Admin-Konto zu verwenden, da Super Admin-Konten von der Einmalanmeldung ausgenommen sind (d. h., die Konfiguration für die Einmalanmeldung gilt nicht für sie; sie verwenden weiterhin Passwörter für die Anmeldung).

In diesem Szenario können Sie Azure AD jedoch ein eingeschränkteres Konto für die Migration verwenden lassen, mit dem Azure AD keine Nutzer erstellen kann. So verhindern Sie, dass Azure automatisch Nutzerkonten für Identitäten mit Privatnutzerkonten bereitstellt, unabhängig davon, welche Nutzer der Nutzerverwaltungs-Anwendung zugewiesen sind.

Ein eingeschränktes Admin-Nutzerkonto in Cloud Identity oder in der G Suite sollte nur diese Berechtigungen haben:

  • Organisationseinheiten > Lesen
  • Nutzer > Lesen
  • Nutzer > Aktualisieren
  • Gruppen

Ein Nachteil dieser Methode ist, dass Sie für Nutzer, die keine Konten ohne Verwaltung haben, manuell Konten in Cloud Identity oder der G Suite erstellen müssen.

Mit Azure AD föderieren: Vergleich

Die folgende Tabelle fasst die Methoden zusammen.

Einmalanmeldung für Identitäten mit Privatnutzerkonten zulassen Automatische Nutzerverwaltung für Identitäten mit Privatnutzerkonten verhindern Löschen migrierter Konten ohne übereinstimmende Identität beim externen IdP verhindern Automatisch neue Konten bereitstellen Automatisch migrierte Konten aktualisieren
Methode 1: Keine Nutzerverwaltung X X
Methode 2: Zwei Anwendungen mit manueller Zuweisung Anfällig für manuelle Fehler
Methode 3: Zwei Anwendungen mit deaktivierter Nutzererstellung X

Active Directory-Föderation für die Kontokonsolidierung sichern

Wenn Sie Cloud Identity oder die G Suite mit Active Directory föderieren möchten, können Sie Google Cloud Directory Sync und Active Directory Federation Services (AD FS) verwenden. Bei der Konfiguration von Cloud Directory Sync und AD FS müssen Sie Folgendes tun:

Es gibt mehrere Möglichkeiten, diese Anforderungen zu erfüllen. Jede Methode hat Vor- und Nachteile.

Methode 1: Cloud Directory Sync deaktivieren

Bei dieser Methode richten Sie die Einmalanmeldung mit AD FS ein, aber Sie aktivieren Cloud Directory Sync erst, nachdem Sie die Migration nicht verwalteter Nutzerkonten abgeschlossen haben. Durch die Deaktivierung von Cloud Directory Sync verhindern Sie die automatische Nutzerverwaltung für Identitäten mit Privatnutzerkonten.

Wenn Sie die Einmalanmeldung für Identitäten mit Privatnutzerkonten zulassen möchten, erstellen Sie eine benutzerdefinierte Richtlinie für die Zugriffssteuerung in AD FS und weisen Sie alle Identitäten zu, die möglicherweise letztendlich Zugriff auf Google-Dienste benötigen. Dies gilt auch, wenn ihre vorhandenen Privatnutzerkonten noch migriert werden müssen.

Für einen Nutzer mit einem vorhandenen Privatnutzerkonto wird das entsprechende Cloud Identity- oder G Suite-Nutzerkonto automatisch erstellt, wenn die Übertragungsanfrage angenommen wird. Durch die Verwendung der benutzerdefinierten Richtlinie für die Zugriffssteuerung kann der Nutzer die Einmalanmeldung sofort verwenden.

Nutzer, die kein Nutzerkonto in Cloud Identity oder der G Suite haben, müssen manuell eines erstellen.

Obwohl bei dieser Methode die Anforderungen erfüllt werden und die Einrichtung am einfachsten ist, wird zwar das Risiko vermieden, besteht aber die Einschränkung, dass in Active Directory durchgeführte Attributänderungen oder Nutzersperrungen nicht an Cloud Identity oder die G Suite weitergegeben werden.

Methode 2: Cloud Directory Sync mit manueller Zuweisung

Bei dieser Methode umgehen Sie die Einschränkung, Konten in Cloud Identity oder in der G Suite manuell für Nutzer erstellen zu müssen, die kein vorhandenes Konto haben.

Eine wichtige Einschränkung dieser Methode besteht darin, dass Sie das Löschen migrierter Konten ohne übereinstimmende Identität beim externen IdP nicht verhindern können. Die Methode lässt sich daher nur anwenden, wenn Sie keine Privatnutzerkonten ohne übereinstimmende Identität beim externen IdP haben.

Methode 3: Cloud Directory Sync daran hindern, Nutzer zu erstellen

Beim Konfigurieren der Nutzerverwaltung müssen Sie Cloud Directory Sync autorisieren, auf Cloud Identity oder die G Suite zuzugreifen. Normalerweise ist es am besten, zu diesem Zweck ein spezielles Super Admin-Konto zu verwenden, da diese Konten von der Einmalanmeldung ausgenommen sind (d. h., die Konfiguration für die Einmalanmeldung gilt nicht für sie; sie verwenden weiterhin Passwörter für die Anmeldung).

In diesem Szenario können Sie Cloud Directory Sync jedoch ein eingeschränkteres Konto für die Migration verwenden lassen, mit dem es keine Nutzer erstellen kann. So verhindern Sie, dass Cloud Directory Sync automatisch Nutzerkonten für Identitäten mit Privatnutzerkonten bereitstellt und migrierte Konten ohne übereinstimmende Identität beim IdP löscht.

Ein eingeschränktes Admin-Nutzerkonto in Cloud Identity oder in der G Suite darf nur die folgenden Berechtigungen haben:

  • Organisationseinheiten
  • Nutzer > Lesen
  • Nutzer > Aktualisieren
  • Gruppen
  • Schemaverwaltung
  • Domainverwaltung

Ein Nachteil dieser Methode ist, dass Sie für Nutzer, die keine Konten ohne Verwaltung haben, manuell Konten in Cloud Identity oder der G Suite erstellen müssen.

Mit Active Directory föderieren: Vergleich

Die folgende Tabelle fasst die Methoden zusammen.

Einmalanmeldung für Identitäten mit Privatnutzerkonten zulassen Automatische Nutzerverwaltung für Identitäten mit Privatnutzerkonten verhindern Löschen migrierter Konten ohne übereinstimmende Identität beim externen IdP verhindern Automatisch neue Konten bereitstellen Automatisch migrierte Konten aktualisieren
Methode 1: Nutzerverwaltung nicht konfigurieren X X
Methode 2: GCDS mit manueller Zuweisung Anfällig für manuelle Fehler X
Methode 3: GCDS daran hindern, Nutzer zu erstellen X

Okta-Föderation für die Kontokonsolidierung sichern

Für eine Föderation von Cloud Identity oder der G Suite mit Okta können Sie die G Suite- oder Google Cloud-Anwendungen aus der Anwendungsbibliothek auf der Verwaltungsoberfläche von Okta verwenden. Da sich die Funktionen der Anwendungen ergänzen, müssen Sie sie möglicherweise in Kombination verwenden:

Wenn Sie die G Suite-Anwendung für die Nutzerverwaltung verwenden, ignoriert Okta vorhandene Nutzer in Cloud Identity oder in der G Suite, die kein Gegenstück in Okta haben. So wird die Anforderung erfüllt, dass das Löschen migrierter Konten ohne übereinstimmende Identität beim externen IdP verhindert werden muss.

Je nachdem, wie Sie Okta konfigurieren, müssen Sie trotzdem Folgendes tun:

Es gibt mehrere Möglichkeiten, diese Anforderungen zu erfüllen. Jede Methode hat Vor- und Nachteile.

Methode 1: Nutzerverwaltung nicht konfigurieren

Bei dieser Methode konfigurieren Sie die G Suite oder die Google Cloud-Anwendung für die Verarbeitung der Einmalanmeldung, konfigurieren jedoch überhaupt keine Nutzerverwaltung. Wenn Sie die Nutzerverwaltung nicht konfigurieren, verhindern Sie die automatische Nutzerverwaltung für Identitäten mit Privatnutzerkonten.

Wenn Sie die Einmalanmeldung für Identitäten mit Privatnutzerkonten zulassen möchten, weisen Sie der Anwendung alle Identitäten zu, die möglicherweise letztendlich Zugriff auf Google-Dienste benötigen. Dies gilt auch, wenn ihre bestehenden Privatnutzerkonten noch migriert werden müssen. Die G Suite- oder Google Cloud-Symbole werden auf der Okta-Startseite aller Identitäten angezeigt, die der Anwendung zugewiesen wurden. Die Anmeldung schlägt jedoch fehl, sofern kein entsprechendes Konto auf Google-Seite vorhanden ist.

Für einen Nutzer mit einem vorhandenen Privatnutzerkonto wird das entsprechende Cloud Identity- oder G Suite-Nutzerkonto automatisch erstellt, wenn die Übertragungsanfrage angenommen wird. Dieser Nutzer kann die Einmalanmeldung sofort verwenden.

Obwohl bei dieser Methode die Anforderungen erfüllt werden und die Einrichtung am einfachsten ist, wird zwar das Risiko vermieden, besteht aber die Einschränkung, dass in Okta durchgeführte Attributänderungen oder Nutzersperrungen nicht an Cloud Identity oder die G Suite weitergegeben werden. Ein weiterer Nachteil dieser Methode ist, dass Sie für alle Nutzer ohne vorhandenes Privatnutzerkonto manuell Konten in Cloud Identity oder der G Suite erstellen müssen.

Methode 2: Nutzerverwaltung mit manueller Zuweisung

Bei dieser Methode konfigurieren Sie die G Suite-Anwendung für die Verarbeitung der Einmalanmeldung und Nutzerverwaltung. Sie aktivieren aber nur die folgenden Funktionen:

  • Nutzer erstellen
  • Nutzerattribute aktualisieren
  • Nutzer deaktivieren

Zum Hinzufügen des Google Cloud-Symbols zu den Okta-Startseiten der Nutzer können Sie die Google Cloud-Anwendung optional konfigurieren. Wenn Sie der Anwendung Identitäten zuweisen, schließen Sie die Identitäten ein, die letztendlich Zugriff auf Google-Dienste benötigen, schließen jedoch alle Identitäten aus, die bekanntermaßen ein vorhandenes Privatnutzerkonto haben. So verhindern Sie die automatische Nutzerverwaltung für Identitäten mit Privatnutzerkonten.

Sobald ein Nutzer eine Übertragungsanfrage annimmt, weisen Sie ihn der Anwendung zu, damit er die Einmalanmeldung verwenden und auf die G Suite oder Google Cloud zugreifen kann.

Ein Nachteil dieser Methode besteht darin, dass jeder Fehler, den Sie bei der Zuweisung machen, sofort zur Erstellung eines in Konflikt stehenden Kontos führen kann, was diese Methode wesentlich riskanter macht als die anderen Methoden.

Ein weiterer Nachteil dieser Methode ist, dass sie zur vorübergehenden Sperrung migrierter Konten führt. Nachdem ein Nutzer eine Übertragungsanfrage angenommen hat, muss er alle darauffolgenden Anmeldungen über Okta durchführen. Diese Anmeldeversuche schlagen fehl, bis Sie den Nutzer der Anwendung in Okta zugewiesen haben.

Methode 3: Nutzerverwaltung mit deaktivierter Nutzererstellung

Bei dieser Methode konfigurieren Sie die G Suite für die Verarbeitung der Einmalanmeldung und Nutzerverwaltung. Sie aktivieren aber nur die folgenden Funktionen:

  • Nutzerattribute aktualisieren
  • Nutzer deaktivieren

Sie lassen die Option Nutzer erstellen deaktiviert.

Zum Hinzufügen des Google Cloud-Symbols zu den Okta-Startseiten der Nutzer können Sie die Google Cloud-Anwendung optional konfigurieren. Sie weisen der Anwendung alle Identitäten zu, die letztendlich Zugriff auf Google-Dienste benötigen. Schließen Sie dabei Identitäten mit vorhandenen Privatnutzerkonten ein, damit Sie die Einmalanmeldung für Identitäten mit Privatnutzerkonten zulassen.

Wenn Sie Okta die Erlaubnis entziehen, Konten zu erstellen, verhindern Sie, dass Okta automatisch Nutzerkonten für Identitäten mit Privatnutzerkonten erstellt. Gleichzeitig kann Okta in dieser Konfiguration immer noch Attributänderungen und Nutzersperrungen an Cloud Identity oder die G Suite weitergeben, sofern der Nutzer über ein entsprechendes Google-Konto verfügt.

Bei Identitäten, für die es kein entsprechendes Nutzerkonto in Cloud Identity oder der G Suite gibt, zeigt Okta möglicherweise eine Fehlermeldung in der Admin-Konsole von Okta an:

Okta-Fehlermeldung

Für einen Nutzer mit einem vorhandenen Privatnutzerkonto wird das entsprechende Cloud Identity- oder G Suite-Nutzerkonto automatisch erstellt, wenn die Übertragungsanfrage angenommen wird. Dieser Nutzer kann die Einmalanmeldung sofort verwenden. Obwohl das Nutzerkonto zu diesem Zeitpunkt funktionsfähig ist, zeigt Okta möglicherweise noch kein Symbol auf der Startseite des Nutzers an, sondern stattdessen eventuell weiterhin die Fehlermeldung in der Admin-Benutzeroberfläche. Damit Sie dies beheben können, wiederholen Sie die Zuweisungsaufgabe im Okta Administrator Dashboard.

Durch diese Methode wird verhindert, dass Okta automatisch Nutzerkonten für Identitäten mit Privatnutzerkonten erstellt. Die Einmalanmeldung für Identitäten mit Privatnutzerkonten wird jedoch weiter zugelassen. Diese Methode ist auch weniger anfällig für versehentliche Fehlkonfigurationen als die zweite. Ein Nachteil ist, dass Sie für Nutzer ohne vorhandene Privatnutzerkonten manuell Konten in Cloud Identity oder der G Suite erstellen müssen.

Methode 4: Zwei Anwendungen mit manueller Zuweisung

Sie können einige der Nachteile der vorherigen Methoden überwinden, indem Sie zwei Anwendungen verwenden, eine für die Nutzerverwaltung und eine für die Einmalanmeldung:

  • Konfigurieren Sie die G Suite-Anwendung so, dass sie ausschließlich die Nutzerverwaltung verarbeitet. Die Einmalanmeldungs-Funktion der Anwendung wird nicht verwendet. Durch die Zuweisung von Nutzern an diese Anwendung steuern Sie, welche Konten für Cloud Identity oder die G Suite bereitgestellt werden. Sie können gewährleisten, dass diese Anwendung für Ihre Nutzer erfolgreich ausgeblendet wird, indem Sie die Option Do not display application icon to users (Anwendungssymbol für Nutzer nicht anzeigen) aktivieren.
  • Konfigurieren Sie entweder die Google Cloud-Anwendung oder eine andere Instanz der G Suite-Anwendung nur für die Einmalanmeldung. Wenn Sie dieser Anwendung Nutzer zuweisen, legen Sie fest, wer sich anmelden darf und wer das Google Cloud-Symbol auf der Okta-Startseite sieht.

Beim Verwenden beider Anwendungen können Sie Nutzer so zuweisen:

Mit Okta föderieren: Vergleich

Die folgende Tabelle fasst die Methoden zusammen.

Einmalanmeldung für Identitäten mit Privatnutzerkonten zulassen Automatische Nutzerverwaltung für Identitäten mit Privatnutzerkonten verhindern Löschen migrierter Konten ohne übereinstimmende Identität beim externen IdP verhindern Automatisch neue Konten bereitstellen Automatisch migrierte Konten aktualisieren
Methode 1: Keine Nutzerverwaltung X X
Methode 2: Nutzerverwaltung mit manueller Zuweisung X Riskant
Methode 3: Nutzerverwaltung mit deaktivierter Nutzererstellung X
Methode 4: Zwei Anwendungen mit manueller Zuweisung Riskant

Weitere Informationen