Identitätsbereitstellung (oder Kontobereitstellung) ist der Prozess zum Einrichten von Konten und zum Herstellen von Verbindungen zwischen den drei Systemen, in denen Nutzerdaten gespeichert sind. In einigen Fällen werden auch Verbindungen zwischen Nutzern und ihren Geräten eingerichtet.
In einer Android Enterprise-Umgebung werden Nutzerkontoinformationen in drei verschiedenen Systemen gespeichert:
- Das Nutzerverzeichnis der Organisation ist die maßgebliche Informationsquelle für Nutzer.
- Sie (der EMM-Lösungsanbieter) müssen mindestens ein minimales Verzeichnis der Nutzer der Organisation führen.
- Google speichert einige Informationen zu Managed Google Play-Konten und Google-Konten, um die App-Verwaltung über Google Play zu ermöglichen.
Eine Users-Ressource stellt ein Konto dar, das mit einem Unternehmen verknüpft ist. Das Konto kann für ein bestimmtes Gerät oder für eine Person mit mehreren Geräten bestimmt sein, die das Konto auf allen Geräten verwendet. Das Konto kann je nach Einrichtung der Unternehmensgruppe des Kunden nur Zugriff auf Managed Google Play oder auch auf andere Google-Dienste bieten:
Verwaltete Google-Konten sind bestehende Konten, die von Google verwaltet werden. Für diese Konten muss der Kunde entweder Google als Identitätsanbieter verwenden oder das Nutzerverzeichnis seiner Organisation mit Google verknüpfen. Bei Unternehmen, die verwaltete Google-Konten verwenden, ist Google für die Authentifizierung des Nutzers während der Gerätebereitstellung verantwortlich.
Konten für Managed Google Play bieten Unternehmen die Möglichkeit, über ihren EMM-Lösungsanbieter (Enterprise Mobility Management) automatisch eingeschränkte Nutzerkonten zu erstellen. Mit diesen Konten kann nur auf Managed Google Play zugegriffen werden. Der EMM ist vollständig für die Authentifizierung des Nutzers verantwortlich, wenn dies erforderlich ist. Für Kontogruppen für Managed Google Play ist dies der einzige verfügbare Kontotyp.
Tabelle 1: Felder und Methoden der Users API
| Managed Google Play-Konten | Verwaltete Google-Konten | |
|---|---|---|
| Feld | ||
| id | ||
| Typ | ||
| accountIdentifier | Eine eindeutige Kennung, die Sie erstellen und der von Google Play zurückgegebenen ID (userId) zuordnen. Verwenden Sie keine personenidentifizierbaren Informationen. | Nicht definiert. |
| accountType | deviceAccount, userAccount | userAccount |
| displayName | Der Name, der in UI-Elementen wie Google Play angezeigt wird. Verwenden Sie keine personenidentifizierbaren Informationen. | Nicht definiert. |
| managementType | emmManaged | googleManaged, emmManaged |
| primaryEmail | Nicht definiert. | Dieses Feld ist der Primärschlüssel, mit dem Sie die Synchronisierung von Google-verwalteten Domainkonten mit Nutzerkonten in Ihrem System verwalten. |
| Methoden | ||
| Löschen | ||
| generateAuthenticationToken | ||
| generateToken | ||
| get | ||
| getAvailableProductSet | ||
| insert | ||
| list | ||
| revokeToken | ||
| setAvailableProductSet | ||
| update | ||
Im Rahmen unserer Verbesserungen bei der Geräteregistrierung stellen wir auf verwaltete Google-Konten für alle Android Enterprise-Geräte um, die von Mitarbeitern mit einer Unternehmensidentität verwendet werden.
Für neue Registrierungen empfehlen wir jetzt die Verwendung von verwalteten Google-Konten anstelle von verwalteten Google Play-Konten. Wir unterstützen weiterhin verwaltete Google Play-Konten für bestehende Nutzer, aber sie bieten nur Zugriff auf den verwalteten Google Play Store. Verwaltete Google-Konten bieten Nutzern Zugriff auf die gesamte Palette von Google-Diensten und geräteübergreifenden Funktionen.
Verbesserungen bei der Registrierung
Mit verwalteten Google-Konten wird die Identität eines Nutzers bei Google festgelegt. Dies ermöglicht geräteübergreifende Funktionen wie die Übergabe von Aufgaben, Benachrichtigungen und die gemeinsame Nutzung in der Nähe. Diese Funktionen werden im Unternehmensbereich, in dem Nutzer häufig mehrere Geräte verwenden, immer wichtiger.
Unternehmen, die Google nicht als Identitätsanbieter verwenden, wird jetzt dringend empfohlen, ihren vorhandenen Identitätsanbieter mit Google zu verknüpfen. Dadurch können während des Bindungsvorgangs verwaltete Google-Konten für Mitarbeiter erstellt werden. Unternehmen sollten dafür denselben Identitätsanbieter verwenden wie für ihr EMM.
Wir haben die folgenden Änderungen vorgenommen:
Die Authentifizierung des Endnutzers während der Geräteregistrierung wird jetzt von Google/Android übernommen. Der Device Policy Controller (DPC) des EMM erfordert, dass Android den Nutzer an der entsprechenden Stelle authentifiziert. Android gibt dann die Identität des angemeldeten Nutzers an den DPC zurück.
Das EMM muss ein Registrierungstoken an Android übergeben, wenn es die Nutzerauthentifizierung anfordert. Dieses Token wird von einem API-Aufruf an die Android Enterprise API zurückgegeben und kann im QR-Code, NFC-Tag oder in der Zero-Touch-Registrierungs-Payload codiert sein.
Android übernimmt jetzt die Authentifizierung und stellt dem EMM die Nutzeridentität zur Verfügung. Es liegt jedoch weiterhin in der Verantwortung des EMM, die Nutzeridentität der richtigen Gruppe oder Organisationsstruktur zuzuordnen. Diese Zuordnung ist wichtig, damit die entsprechenden Richtlinien auf das Gerät angewendet werden können. Unternehmen müssen daher weiterhin das Nutzerverzeichnis ihrer Organisation mit ihrem EMM verknüpfen.
IT‑Administratoren können die neue von Google bereitgestellte Endnutzerauthentifizierung aktivieren oder deaktivieren. Damit Nutzer die bestmögliche Erfahrung haben, einschließlich geräteübergreifender Funktionen, empfehlen wir IT-Administratoren, das Nutzerverzeichnis ihrer Organisation mit Google zu verknüpfen. Ohne diese Verknüpfung haben Nutzer verwaltete Google-Konten und keinen Zugriff auf geräteübergreifende Funktionen.
Alle EMMs müssen zusätzliche Informationen angeben, wenn sie Registrierungs- und Anmeldetokens erstellen. Sie müssen jetzt angeben, ob ein Gerät ohne Nutzer ist (z. B. ein Kiosk oder ein zweckbestimmtes Gerät).
Vorteile
Das neue Verfahren bietet folgende wichtige Verbesserungen:
Vereinfachte Registrierung:Im Vergleich zu Standardmethoden sind weniger manuelle Schritte erforderlich und die Komplexität wird reduziert.
Unterstützung von Google-Konten:Sie können jetzt Google-Konten mit allen Bereitstellungsmethoden verwenden. Dadurch sind keine Konten für Managed Google Play mehr erforderlich.
Verbesserte Nutzerfreundlichkeit:Mit verwalteten Google-Konten erhalten Sie eine umfassendere Android-Erfahrung mit leistungsstarken geräteübergreifenden Funktionen wie Freigabe und Kopieren und Einfügen.
Implementierung von Nutzerkonten
Informationen dazu, wie Sie bei diesem neuen Registrierungsablauf vorgehen müssen, finden Sie unter Nutzerkonten implementieren.
Lebenszyklus verwalteter Google-Konten
Bei Organisationen, die Google-Konten verwenden, spiegeln Nutzerkonten in der EMM-Lösung vorhandene Nutzerkonten, die mit einem anderen Google-Dienst (z. B. Google Workspace) verknüpft sind. Diese Konten sind googleManaged (Tabelle 1), da die Backend-Dienste von Google die Quelle für die Erstellung und die Informationen zum Konto sind.
Als EMM können Sie in Ihrer Konsole Mechanismen bereitstellen, um die Erstellung und laufende Synchronisierung von Nutzerkonten in Ihrem System mit den entsprechenden Google-Domainkonten zu ermöglichen. Dazu können Sie Tools wie Google Cloud Directory Sync (GCDS) und die Google Admin SDK Directory API verwenden. Weitere Informationen Für das von Google verwaltete Identitätsmodell für Domains muss das Nutzerkonto im Kontext Ihrer Lösung (EMM-Konsole, EMM-Server, möglicherweise in einem Datenspeicher) vorhanden sein, bevor es auf einem der Geräte des Nutzers im Kontext eines Arbeitsprofils bereitgestellt werden kann.
Bei der Identitätsbereitstellung wird die von Google verwaltete Domain der Organisation mit Nutzerkonten gefüllt. In einigen Fällen werden die vorhandenen Onlineidentitäten der Nutzer (z. B. ihre Microsoft Exchange-Konten) mit ihren Google-Konten synchronisiert.
Kundenkonten synchronisieren
Bei einer Bereitstellung von Google-Konten kann die Organisation das GCDS-Tool verwenden, um die Daten in ihrer G Suite-Domain mit den Daten in ihrem LDAP-Verzeichnis zu synchronisieren. Alternativ können Sie GCDS verwenden, um dies im Namen der Organisation zu tun, sofern die Organisation Ihnen Zugriff gewährt.
Das GCDS-Tool ruft die Google Directory API auf und synchronisiert Nutzernamen, aber keine Passwörter.
Wenn die Organisation Microsoft Active Directory verwendet und die G Suite-Passwörter der Nutzer mit ihren Active Directory-Passwörtern synchronisiert werden sollen, kann sie oder Sie das Tool G Suite Password Sync (GSPS) mit GCDS verwenden.
Eine Anleitung für Administratoren zur Verwendung von GCDS finden Sie unter Google-Domain vorbereiten.
Google Directory API
Bei einer Bereitstellung von Google-Konten können Sie die Google Directory API verwenden, um Active Directorys, Passwörter oder beides zu synchronisieren:
Directory API für die reine Verzeichnissynchronisierung verwenden Wenn Sie Lesezugriff auf die verwaltete Google-Domain der Organisation haben, können Sie mit der Google Directory API Google-Kontoinformationen wie Nutzernamen (aber nicht Passwörter) von Google abrufen. Da Sie keine Daten in die Google-Konten der Nutzer schreiben können, ist die Organisation vollständig für den Lebenszyklus der Konten verantwortlich.
Szenario 1 und SAML-basierte SSO-Authentifizierungsszenarien beschreiben diese Situation genauer.
Informationen zur Verwendung der Directory API auf diese Weise finden Sie in der Directory API-Dokumentation unter Alle Kontonutzer abrufen.
Verwenden der Directory API für die Verzeichnis- und optionale Passwortsynchronisierung Wenn Sie Lese-/Schreibzugriff auf die verwaltete Google-Domain der Organisation haben, können Sie die Google Directory API verwenden, um Nutzernamen, Passwörter und andere Google-Konto-Informationen abzurufen. Sie können diese Informationen aktualisieren und mit Ihrer eigenen Datenbank synchronisieren. Je nach der Lösung, die Sie Ihrem Kunden anbieten, sind Sie möglicherweise ganz oder teilweise für den Lebenszyklus des Kontos verantwortlich.
Szenario 2 beschreibt diese Situation genauer.
Weitere Informationen zur Verwendung der Directory API zum Verwalten von Nutzerkontoinformationen finden Sie im Entwicklerleitfaden Directory API: User Accounts.
Szenarien für Google-Konten
Im folgenden Abschnitt werden einige typische Szenarien für die Identitätsbereitstellung für Google-Konten beschrieben.
Szenario 1: Kunde ist für den Lebenszyklus von Konten verantwortlich
In diesem Szenario erstellt und verwaltet Ihr Kunde Google-Konten für seine Nutzer.
Sie rufen Nutzerkontoinformationen aus dem LDAP-Verzeichnis der Organisation ab und gleichen diese mit Google-Kontodaten ab, die Sie von Google über die Google Directory API erhalten.
Die Organisation ist vollständig für den Lebenszyklus von Konten verantwortlich. Wenn beispielsweise ein neues Google-Konto erstellt wird, fügt die Organisation den Nutzer ihrem LDAP-Verzeichnis hinzu. Wenn Sie Ihre Datenbank das nächste Mal mit dem LDAP-Verzeichnis synchronisieren, erhält sie Informationen zu diesem neuen Nutzer.
Für dieses Beispiel gilt:
- Sie haben nur Lesezugriff auf Google-Konten.
- Ihre Datenbank enthält Google-Kontonamen, aber keine LDAP-Nutzernamen oder ‑Passwörter.
- Sie verwenden die Google Directory API, um grundlegende Kontoinformationen für die Nutzer Ihres Kunden abzurufen. Die für Sie verfügbaren Informationen sind die nicht schreibbaren Informationen, die von einer
Users.get-Anfrage zurückgegeben werden. Mit diesen Informationen wird überprüft, ob die Google-Konten der Nutzer vorhanden sind, damit sich Nutzer auf ihren Geräten authentifizieren können. - Ihr Kunde verwendet das GCDS-Tool für eine unidirektionale Synchronisierung, um die Google-Konten der Nutzer zu füllen. Die Organisation verwendet GCDS wahrscheinlich auch für die laufende Synchronisierung, nachdem die Identitätsbereitstellung abgeschlossen ist. Optional kann die Organisation auch das Tool GSPS verwenden, um nicht nur Nutzernamen, sondern auch Passwörter zu synchronisieren.
Szenario 2: EMM für Kontolebenszyklen verantwortlich
In diesem Szenario erstellen Sie Google-Konten im Namen Ihres Kunden und sind für den Lebenszyklus der Nutzerkonten verantwortlich.
Wenn sich beispielsweise Nutzerinformationen im LDAP-Verzeichnis der Organisation ändern, sind Sie dafür verantwortlich, das Google-Konto des Nutzers zu aktualisieren. GCDS wird in diesem Szenario nicht verwendet.
Für dieses Beispiel gilt:
- Sie haben Lese-/Schreibzugriff auf Google-Konten.
- Ihre Datenbank enthält Google-Kontonamen und LDAP-Nutzernamen (und optional Passwort-Hashes).
- Sie verwenden die Google Directory API im Namen Ihres Kunden, um Kontoinformationen für die Nutzer der Organisation zu lesen und zu schreiben. Die für Sie verfügbaren Informationen sind die nicht schreibbaren Informationen, die von einer
Users.get-Anfrage zurückgegeben werden. Mit diesen Informationen wird überprüft, ob die Google-Konten der Nutzer vorhanden sind, damit sich Nutzer auf ihren Geräten authentifizieren können. - Das GCDS-Tool wird nicht verwendet.
Szenarien für die SAML-basierte SSO-Authentifizierung
Bei einer Google-Konten-Bereitstellung verwenden Sie oder Ihr Kunde möglicherweise SAML (Security Assertion Markup Language) mit einem Identitätsanbieter (IdP), um das Google-Konto zu authentifizieren, das jedem Nutzer zugeordnet ist. Sie verwenden die Namen der Google-Konten als Bestätigung dafür, dass die Google-Konten der Nutzer vorhanden sind. Dies ist für die Nutzerauthentifizierung erforderlich, wenn sich Nutzer auf ihren Geräten anmelden. SAML könnte beispielsweise in Szenario 2 verwendet werden. Weitere Informationen zur Einrichtung finden Sie unter Einmalanmeldung (SSO) für verwaltete Google-Konten mit anderen Identitätsanbietern einrichten.