Wenn Sie Cloud Identity oder Google Workspace 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 Google Workspace mit einer externen autoritativen Quelle, sodass diese automatisch Nutzerkonten in Cloud Identity oder Google Workspace bereitstellen kann.
Diese Invarianten gelten normalerweise für eine föderierte Einrichtung:
- Die autoritative Quelle ist die einzige Quelle für Identitäten.
- In Cloud Identity oder Google Workspace gibt es nur Nutzerkonten, die von der autoritativen Quelle bereitgestellt wurden.
- 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:
- 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.
- Bestehende Privatnutzerkonten sind nach der Migration zu Cloud Identity oder Google Workspace Nutzerkonten, die nicht von der autoritativen Quelle bereitgestellt wurden. Die autoritative Quelle muss diese migrierten Konten erkennen und "übernehmen".
- 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 Google Workspace-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 Google Workspace übertragen.
Zum Standardverhalten vieler externer IdPs gehört die proaktive Erstellung von Nutzerkonten in Cloud Identity oder Google Workspace. 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 Google Workspace 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 Google Workspace 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. |
Microsoft Entra ID-Föderation (früher Azure AD) für die Kontokonsolidierung sichern
Wenn Sie Cloud Identity oder Google Workspace mit Microsoft Entra ID (früher Azure AD) föderieren möchten, können Sie die Google Workspace Gallery-Anwendung verwenden.
Wenn Sie die Nutzerverwaltung aktivieren, ignoriert Microsoft Entra ID bestehende Konten in Cloud Identity oder Google Workspace, die kein Gegenstück in Microsoft Entra ID haben. So wird die Anforderung, das Löschen von migrierten Konten ohne eine passende Identität im externen IdP zu verhindern, immer erfüllt.
Je nachdem, wie Sie die Gallery-Anwendung konfigurieren, müssen Sie weiterhin Folgendes gewährleisten:
- Einmalanmeldung für Identitäten mit Privatnutzerkonten zulassen
- Automatische Nutzerverwaltung für Identitäten mit Privatnutzerkonten verhindern
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 Google Workspace-Nutzerkonto automatisch erstellt, wenn die Übertragungsanfrage angenommen wird. Dieser Nutzer kann die Einmalanmeldung sofort verwenden.
Nutzer, die kein Nutzerkonto in Cloud Identity oder Google Workspace haben, müssen manuell eines erstellen.
Diese Methode erfüllt zwar die Anforderungen und ist am einfachsten einzurichten, doch geht sie mit der Einschränkung einher, dass in Microsoft Entra ID durchgeführte Attributänderungen oder Nutzersperrungen nicht an Cloud Identity oder Google Workspace weitergegeben werden.
Methode 2: Zwei Anwendungen mit manueller Zuweisung
Bei dieser Methode umgehen Sie die Einschränkung, Konten in Cloud Identity oder Google Workspace manuell für Nutzer erstellen zu müssen, die noch kein 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 Google Workspace 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:
- Weisen Sie der SSO-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 der Nutzerverwaltungs-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.
Methode 3: Zwei Anwendungen mit deaktivierter Nutzererstellung
Beim Konfigurieren der Nutzerverwaltung müssen Sie Microsoft Entra ID autorisieren, über ein Cloud Identity- oder Google Workspace-Konto auf Cloud Identity oder Google Workspace 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 Microsoft Entra ID jedoch ein eingeschränkteres Konto für die Migration verwenden lassen, mit dem Microsoft Entra ID 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 Google Workspace darf nur die folgenden 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 Google Workspace erstellen müssen.
Föderation mit Microsoft Entra ID: 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 das Konto sichern
Wenn Sie Cloud Identity oder Google Workspace mit Active Directory föderieren möchten, können Sie Google Cloud Directory Sync (GCDS) und Active Directory Federation Services (AD FS) verwenden. Bei der Konfiguration von GCDS und AD FS müssen Sie Folgendes tun:
- 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
Es gibt mehrere Möglichkeiten, diese Anforderungen zu erfüllen. Jede Methode hat Vor- und Nachteile.
Methode 1: GCDS deaktivieren
Bei dieser Methode richten Sie die Einmalanmeldung mit AD FS ein, aber Sie aktivieren GCDS erst, nachdem Sie die Migration nicht verwalteter Nutzerkonten abgeschlossen haben. Wenn Sie GCDS deaktivieren, 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 Google Workspace-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 Google Workspace haben, müssen manuell eines erstellen.
Diese Methode erfüllt zwar die Anforderungen und ist am einfachsten einzurichten, doch geht sie mit der Einschränkung einher, dass in Okta durchgeführte Attributänderungen oder Nutzersperrungen nicht an Cloud Identity oder Google Workspace weitergegeben werden.
Methode 2: GCDS mit manueller Zuweisung
Bei dieser Methode umgehen Sie die Einschränkung, Konten in Cloud Identity oder Google Workspace manuell für Nutzer erstellen zu müssen, die noch kein Konto haben.
Wie bei Methode 1 lassen Sie die Einmalanmeldung für Identitäten mit Privatnutzerkonten zu. Dazu erstellen eine benutzerdefinierte Richtlinie für die Zugriffssteuerung in AD FS und weisen 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.
Erstellen Sie in Active Directory eine Gruppe mit den Nutzerkonten, die Sie automatisch für GCDS bereitstellen möchten. Fügen Sie der Liste der Mitglieder die Identitäten hinzu, die letztendlich Zugriff auf Google-Dienste benötigen. Schließen Sie jedoch alle Identitäten aus, die bekanntermaßen ein vorhandenes Privatnutzerkonto haben.
Konfigurieren Sie GCDS so, dass Nutzerkonten nur für Identitäten bereitgestellt werden, die Mitglieder dieser Gruppe sind. So verhindern Sie die automatische Nutzerverwaltung für Identitäten mit Privatnutzerkonten.
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: GCDS daran hindern, Nutzer zu erstellen
Beim Konfigurieren der Nutzerverwaltung müssen Sie GCDS autorisieren, auf Cloud Identity oder Google Workspace 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 GCDS jedoch ein eingeschränkteres Konto für die Migration verwenden lassen, mit dem es keine Nutzer erstellen kann. So verhindern Sie, dass GCDS automatisch Nutzerkonten für Identitäten mit Privatnutzerkonten bereitstellt und migrierte Konten ohne übereinstimmende Identität beim IdP löscht.
Ein eingeschränktes Administratorkonto in Cloud Identity oder Google Workspace sollte 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 Google Workspace 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 Google Workspace mit Okta können Sie die Google Workspace-Anwendung aus dem Okta-Anwendungskatalog verwenden. Diese Anwendung kann die Einmalanmeldung (SSO) verarbeiten und Nutzer und Gruppen in Cloud Identity oder Google Workspace bereitstellen.
Wenn Sie die Google Workspace-Anwendung für die Nutzerverwaltung verwenden, ignoriert Okta vorhandene Nutzer in Cloud Identity oder Google Workspace, die kein Gegenstück in Okta haben. So wird immer 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:
- Einmalanmeldung für Identitäten mit Privatnutzerkonten zulassen
- Automatische Nutzerverwaltung für Identitäten mit Privatnutzerkonten verhindern
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 Google Workspace-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 Google Workspace- 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 Google Workspace-Nutzerkonto automatisch erstellt, wenn die Übertragungsanfrage angenommen wird. Dieser Nutzer kann die Einmalanmeldung sofort verwenden.
Diese Methode erfüllt zwar die Anforderungen und ist am einfachsten einzurichten, doch geht sie mit der Einschränkung einher, dass in Okta durchgeführte Attributänderungen oder Nutzersperrungen nicht an Cloud Identity oder Google Workspace weitergegeben werden. Ein weiterer Nachteil dieser Methode ist, dass Sie in Cloud Identity oder Google Workspace manuell Konten für alle Nutzer erstellen müssen, die noch kein Privatnutzerkonto haben.
Methode 2: Nutzerverwaltung mit manueller Zuweisung
Bei dieser Methode konfigurieren Sie die Google Workspace-Anwendung für die Verarbeitung der Einmalanmeldung und Nutzerverwaltung. Sie aktivieren aber nur die folgenden Verwaltungsfunktionen:
- Nutzer erstellen
- Nutzerattribute aktualisieren
- Nutzer deaktivieren
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 Google Workspace 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 Google Workspace für die Verarbeitung der Einmalanmeldung und Nutzerverwaltung. Sie aktivieren aber nur die folgenden Verwaltungsfunktionen:
- Nutzerattribute aktualisieren
- Nutzer deaktivieren
Lassen Sie die Option Nutzer erstellen deaktiviert und weisen Sie der Anwendung alle Identitäten zu, die letztendlich Zugriff auf Google-Dienste benötigen. Schließen Sie 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 Google Workspace 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 Google Workspace gibt, zeigt Okta möglicherweise eine Fehlermeldung in der Admin-Konsole von Okta an:
Für einen Nutzer mit einem vorhandenen Privatnutzerkonto wird das entsprechende Cloud Identity- oder Google Workspace-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 Google Workspace 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 eine Instanz der Google Workspace-Anwendung, die die Bereitstellung ausschließlich übernimmt. 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 Google Workspace 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 eine andere Instanz der Google Workspace-Anwendung nur für die Einmalanmeldung. Indem Sie dieser Anwendung Nutzer zuweisen, steuern Sie, wer sich anmelden darf.
Beim Verwenden beider Anwendungen können Sie Nutzer so zuweisen:
- Weisen Sie der SSO-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 der Nutzerverwaltungs-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.
Immer wenn ein Nutzer eine Übertragungsanfrage annimmt, weisen Sie ihn ebenfalls der Anwendung zu.
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 | ✅ | ✅ | ✅ |
Nächste Schritte
- Weitere Informationen zum Einrichten der Föderation mit Active Directory oder Microsoft Entra ID
- Starten Sie das Onboarding durch Vorbereiten der Cloud der Identity- oder Google Workspace-Konten.