Google Cloud mit Azure Active Directory verbinden

In diesem Artikel wird beschrieben, wie Sie eine auf Microsoft Azure Active Directory basierende vorhandene Identitätsverwaltungslösung auf Google Cloud erweitern, um konsistente Authentifizierungs- und Autorisierungsmechanismen in einer hybriden Rechenumgebung einzurichten. Hinweis: Ein Teil der in diesem Dokument verlinkten Seiten steht nur auf Englisch zur Verfügung.

Einführung

Eine wichtige Aufgabe der IT-Abteilungen von Unternehmen besteht darin, Nutzerkonten zu verwalten und den Mitarbeiterzugriff auf Anwendungen und Rechenressourcen zu steuern. In der Vergangenheit haben sich Unternehmen dafür oft ausschließlich auf ein lokales Active Directory (AD) gestützt, was dieses zu einem Grundpfeiler ihrer IT-Landschaft und lokalen Infrastruktur gemacht hat.

Heutzutage verwenden Unternehmen häufig eine Kombination aus lokalem Active Directory und Azure Active Directory (Azure AD), um die Authentifizierung und Autorisierung zu verwalten. Obwohl vielleicht ein lokales Active Directory für die Verwaltung lokaler Ressourcen verwendet wird und unter Umständen auch als Erfassungssystem zur Verwaltung von Nutzerkonten und -gruppen dient, wird die Authentifizierung und Autorisierung für cloudbasierte Deployments oft mit Azure AD verwaltet.

In diesem Artikel erfahren Sie, wie Sie eine vorhandene Identitätsverwaltungslösung, die auf Active Directory und Azure AD basiert, mithilfe von Cloud Identity auf Google Cloud erweitern können. Die Ausführungen gelten aber auch für die G Suite.

In diesem Artikel wird davon ausgegangen, dass Sie mit Active Directory und Azure AD vertraut sind.

Active Directory, Azure AD und Google Cloud verbinden

Google Cloud verwendet zur Authentifizierung und für die Zugriffsverwaltung Identitäten. Damit ein Mitarbeiter auf Google Cloud-Ressourcen zugreifen kann, muss er eine Google-Identität haben. Die manuelle Verwaltung von Google-Identitäten für jeden Mitarbeiter wäre umständlich, wenn alle Mitarbeiter bereits ein Konto in Active Directory oder Azure AD haben. Wenn Sie aber Nutzeridentitäten in Cloud Identity und Ihrem Identitätsverwaltungssystem miteinander verbinden, können Sie die Verwaltung von Google-Konten automatisieren und deren Lebenszyklen an vorhandene Konten binden.

Falls Sie Active Directory und Azure AD bereits verwenden, haben Sie zur Einbindung von Google Cloud zwei Möglichkeiten:

  1. Sie können Active Directory direkt mit Cloud Identity verbinden. Dazu verwenden Sie Google Cloud Directory Sync und Active Directory Federation Services (AD FS):

    Google Cloud Directory Sync

    Mit diesem Ansatz können Sie zwar genau steuern, wie und was zwischen Active Directory und Cloud Identity zu synchronisieren ist, die Vorteile von Azure AD aber nicht nutzen. Außerdem müssen Sie bei diesem Ansatz Google Cloud Directory Sync und AD FS in Ihrer Rechenumgebung ausführen.

    Weitere Informationen zu diesem Ansatz finden Sie in einer separaten Anleitung.

  2. Sie können Cloud Identity mit Azure AD verbinden, wobei Azure AD selbst mit einer oder mehreren lokalen Active Directory-Gesamtstrukturen verbunden sein könnte:

    Cloud Identity mit Azure AD verbinden

    Ein Vorteil dieses Ansatzes besteht darin, dass Sie keine zusätzliche Software in Ihrer lokalen Umgebung installieren müssen. Die von Azure AD unterstützten Authentifizierungsmechanismen (einschließlich Passthrough-Authentifizierung und Passwort-Hash-Synchronisierung) können auch für Google Cloud verwendet werden.

Im weiteren Verlauf dieses Artikels steht der zweite Ansatz im Mittelpunkt.

Die Verbindung von Azure AD mit Cloud Identity gewährleistet Folgendes:

  • Active Directory und Azure AD bleiben die Single Source Of Truth (SSOT) für die Identitätsverwaltung.
  • Für alle Nutzerkonten in Azure AD oder eine ausgewählte Teilmenge wird automatisch ein Google-Konto erstellt.
  • Wenn ein Konto in Azure AD deaktiviert oder gelöscht wird, wird auch das entsprechende Google-Konto gesperrt oder gelöscht. Im Gegensatz dazu hat das Sperren oder Löschen eines Google-Kontos keine Auswirkungen auf Active Directory, da das Google-Konto bei der nächsten Synchronisierung automatisch neu erstellt wird.
  • Azure AD übernimmt die Nutzerauthentifizierung, sodass Sie keine Passwörter mit Google Cloud synchronisieren müssen.

Die Verbindung von Azure AD mit Cloud Identity gliedert sich in zwei Teile:

  • Bereitstellung von Konten: Relevante Nutzerkonten und -gruppen werden regelmäßig aus Azure AD mit Cloud Identity synchronisiert. Wenn Sie ein neues Konto in Azure AD erstellen oder aus Active Directory mit Azure AD synchronisieren, steht es damit auch in Google Cloud zur Verfügung und kann dort referenziert werden, noch bevor sich der zugehörige Nutzer zum ersten Mal angemeldet hat. Außerdem wird so dafür gesorgt, dass Kontolöschungen übernommen werden.

    Die Bereitstellung läuft in eine Richtung ab. Dies bedeutet, dass Änderungen in Azure AD nach Cloud Identity repliziert werden, jedoch nicht umgekehrt. Außerdem werden Passwörter bei der Bereitstellung nicht verwendet.

  • Einmalanmeldung (SSO): Wenn sich ein Nutzer in Google Cloud authentifizieren muss, delegiert Cloud Identity die Authentifizierung mithilfe des SAML-Protokolls (Security Assertion Markup Language) an Azure AD. In Abhängigkeit von Ihrer Azure AD-Konfiguration führt Azure AD dann einen der folgenden Schritte aus:

    • Führt die Authentifizierung selbst durch
    • Verwendet die Passthrough-Authentifizierung oder die Passwort-Hash-Synchronisierung
    • Delegiert die Authentifizierung an einen lokalen AD FS-Server

Wenn Cloud Identity die Authentifizierung an Azure AD delegiert, ist keine Passwortsynchronisierung mit Google Cloud erforderlich. Außerdem wird gewährleistet, dass alle anwendbaren Richtlinien oder Mechanismen zur Multi-Faktor-Authentifizierung (MFA), die Sie in Azure AD oder AD FS konfiguriert haben, erzwungen werden.

Logische Struktur von Azure AD

Wenn Sie mit Azure arbeiten, verwenden Sie einen oder mehrere Azure AD-Mandanten, die auch Verzeichnisse genannt werden. Azure AD-Mandanten sind eine Struktur auf oberster Ebene. Sie bilden administrative Grenzen und fungieren als Container für Nutzer, Gruppen, Ressourcen und Ressourcengruppen.

Jedem Azure AD-Mandanten ist mindestens eine DNS-Domain zugeordnet. Diese DNS-Domain spiegelt sich in den Nutzernamen wider, die auch User Principal Names oder UPNs genannt werden und das Format [name]@[domain] haben. Dabei ist [domain] eine der DNS-Domains, die dem jeweiligen Mandanten zugeordnet sind.

Logische Struktur von Azure AD

Ein Unternehmen kann mehrere Azure AD-Mandanten verwalten. Oft dienen mehrere Mandanten dazu, zwischen verschiedenen Teilen der Organisation zu unterscheiden, Produktionsressourcen von Entwicklungs- und Testressourcen zu trennen oder mehrere Gesamtstrukturen aus einem lokalen Active Directory einzubinden.

Logische Struktur von Google Cloud

In Google Cloud dienen Organisationen als Container für alle Ressourcen und können mithilfe von Ordnern und Projekten weiter segmentiert werden. Allerdings werden Organisationen mit Ausnahme von Dienstkonten nicht zum Verwalten von Nutzerkonten und -gruppen verwendet, was Organisationen von Azure AD-Mandanten unterscheidet.

Zur Verwaltung von Nutzern und Gruppen stützt sich Google Cloud auf Cloud Identity-Konten oder G Suite-Konten, die jedoch im vorliegenden Dokument nicht behandelt werden.

Logische Struktur der GCP

Mit Cloud Identity können Sie private Verzeichnisse für Nutzerkonten und -gruppen erstellen und verwalten. Jedes private Verzeichnis wird unabhängig verwaltet und kann sich beispielsweise darin unterscheiden, welche Authentifizierungsmethoden zugelassen sind oder welche Passwortrichtlinien erzwungen werden. Verzeichnisse werden in Cloud Identity als Cloud Identity-Konten bezeichnet und anhand von Domainnamen identifiziert.

Wenn Sie ein Cloud Identity-Konto erstellen, wird automatisch eine Google Cloud-Organisation für Sie erstellt und mit dem Cloud Identity-Konto verknüpft. Das Cloud Identity-Konto und die zugehörige Google Cloud-Organisation tragen denselben Namen und sind aneinander gebunden. Eine Google Cloud-Organisation kann aber auf Nutzer und Gruppen aus anderen Cloud Identity-Konten verweisen.

Azure AD in Google Cloud einbinden

Trotz gewisser Ähnlichkeiten zwischen der logischen Struktur von Azure AD und Google Cloud gibt es keine Zuordnung zwischen den beiden Strukturen, die in allen Szenarien gleich gut funktioniert. Der richtige Ansatz für die Verknüpfung der beiden Systeme und die Zuordnung der Struktur hängt vielmehr von mehreren Faktoren ab:

  • Zuordnung von Azure AD-Mandanten zu Cloud Identity-Konten
  • Zuordnung von DNS-Domains
  • Zuordnung von Nutzerkonten
  • Zuordnung von Gruppen

In den folgenden Abschnitten wird individuell auf diese Faktoren eingegangen.

Google Cloud interagiert nur mit Azure AD, nicht mit Ihrem lokalen Active Directory. Daher ist die Zuordnung zwischen den Gesamtstrukturen und Domains Ihres lokalen Active Directory und Azure AD von untergeordneter Bedeutung.

Azure AD-Mandanten zuordnen

Einzelner Mandant

Wenn Sie nur einen einzelnen Azure AD-Mandanten verwenden, können Sie ihn einem einzelnen Cloud Identity-Konto zuordnen und die Verbindung zwischen den beiden einrichten. Dieses Cloud Identity-Konto bildet dann die Basis für eine einzelne Google Cloud-Organisation, mit der Sie alle Google Cloud-Ressourcen verwalten können.

Mandant einem einzelnen Cloud Identity-Konto zuordnen

Mehrere Mandanten

In größeren Unternehmen ist es keine Seltenheit, dass mehrere Azure AD-Mandanten verwendet werden. Mehrere Mandanten können beispielsweise verwendet werden, um zwischen Test- und Produktionsumgebungen oder zwischen verschiedenen Teilen einer Organisation zu unterscheiden.

Obwohl Sie Nutzer und Gruppen aus mehreren Azure AD-Mandanten für ein einzelnes Cloud Identity-Konto bereitstellen können, lässt sich die Einmalanmeldung (SSO) derzeit nicht so konfigurieren, dass sie für Nutzer über mehrere Azure AD-Mandanten hinweg funktioniert. Wenn Sie mehrere Azure AD-Mandanten verwenden, müssen Sie also für jeden Mandanten ein separates Cloud Identity-Konto erstellen und jedes Paar miteinander verbinden.

In Google Cloud wird für jedes Cloud Identity-Konto eine eigene Organisation erstellt. Da Google Cloud die Möglichkeit bietet, Ressourcen innerhalb einer einzelnen Organisation mithilfe von Projekten und Ordnern zu gliedern, ist die Verwendung mehrerer Organisationen eher unpraktisch. Sie können aber eine dieser Organisationen auswählen und den anderen Cloud Identity-Konten zuordnen. So erstellen Sie praktisch eine Organisation, die mit mehreren Active Directory-Gesamtstrukturen verbunden ist. Die übrigen Organisationen bleiben ungenutzt.

Organisation, die mit mehreren Active Directory-Gesamtstrukturen verbunden ist

Externe Nutzer

Mit Azure AD B2B können Sie externe Nutzer als Gäste in Ihren Azure AD-Mandanten einladen. Für jeden Gast wird ein neuer Nutzer erstellt und Azure AD weist diesen Gastnutzern automatisch einen UPN zu. Der von Azure AD generierte UPN enthält ein Präfix, das sich aus der E-Mail-Adresse des eingeladenen Gastes ableitet und mit der Anfangsdomain des Mandanten kombiniert wird: [prefix]#EXT#@[tenant].onmicrosoft.com.

Die Bereitstellung von Gastnutzern aus Azure AD in Cloud Identity unterliegt bestimmten Einschränkungen:

  • Sie können den UPN von Gastnutzern keinen E-Mail-Adressen in Cloud Identity zuordnen. Das liegt daran, dass onmicrosoft.com eine Domain ist, die nicht in Cloud Identity hinzugefügt und verifiziert werden kann. Sie müssen daher zum Zuordnen von Nutzerkonten ein anderes Attribut als den UPN verwenden.
  • Wenn ein Gastnutzer in seinem Home-Mandanten gesperrt ist, bleibt der entsprechende Nutzer in Cloud Identity unter Umständen aktiv und der Zugriff auf Google Cloud-Ressourcen wird möglicherweise nicht ordnungsgemäß widerrufen.

Wenn Gastnutzer von einem anderen Azure AD-Mandant erzeugt werden, können Sie mehrere Cloud Identity-Konten wie im vorherigen Abschnitt beschrieben erstellen und jeweils mit einem anderen Azure AD-Mandanten verbinden.

Ein externer Nutzer muss kein Konto in Cloud Identity haben, um ihm Zugriff auf bestimmte Google Cloud-Ressourcen zu gewähren. Sie können auch den externen Nutzer direkt als Mitglied in die jeweiligen Projekte, Ordner oder Organisationen aufnehmen, sofern der Nutzer ein Google-Konto hat und keine Richtlinie dies verhindert.

DNS-Domains zuordnen

DNS spielt sowohl für Azure AD als auch für Cloud Identity eine entscheidende Rolle. Der zweite Faktor, den Sie beim Verbinden von Azure AD mit Google Cloud berücksichtigen sollten, ist die gemeinsame Nutzung oder Zuordnung von DNS-Domains zwischen Active Directory und Google Cloud.

DNS-Domains in Google Cloud

Auf der Google Identity Platform, die von Google Cloud zur Authentifizierung verwendet wird, werden Nutzer anhand von E-Mail-Adressen identifiziert. Die Verwendung von E-Mail-Adressen garantiert nicht nur, dass Nutzer global eindeutig sind, sondern ermöglicht Google Cloud außerdem, Benachrichtigungen an die Adressen zu senden.

Das Kontoverzeichnis oder der Identitätsanbieter, das oder der zur Authentifizierung eines Nutzers verwendet werden soll, wird auf der Google Identity Platform anhand des Domainteils der E-Mail-Adressen bestimmt, das auf das @ folgt. Für eine E-Mail-Adresse, die die Domain gmail.com verwendet, zieht die Google Identity Platform beispielsweise das Verzeichnis der Gmail-Nutzerkonten zur Authentifizierung heran.

DNS-Domains in der GCP

Wenn Sie sich für ein G Suite- und Cloud Identity-Konto anmelden, erstellen Sie im Prinzip ein privates Verzeichnis, das die Google Identity Platform zur Authentifizierung verwenden kann. So wie das Gmail-Verzeichnis der Domain gmail.com zugeordnet ist, müssen G Suite- und Cloud Identity-Konten einer benutzerdefinierten Domain zugeordnet sein. Zu diesem Zweck werden drei verschiedene Arten von Domains verwendet:

  • Primäre Domain: Diese Domain identifiziert das Cloud Identity-Konto und wird als Name für die Organisation in Google Cloud verwendet. Diesen Domainnamen müssen Sie bei der Anmeldung für Cloud Identity angeben.
  • Sekundäre Domain: Neben der primären Domain können Sie einem Cloud Identity-Verzeichnis weitere sekundäre Domains zuordnen. Jedes Konto im Verzeichnis ist entweder mit der primären Domain oder einer sekundären Domain verknüpft. Die zwei Konten johndoe@example.com und johndoe@secondary.example.com werden als separate Konten betrachtet, wenn example.com die primäre Domain und secondary.example.com die sekundäre Domain eines Verzeichnisses ist.
  • Aliasdomain: Eine Aliasdomain ist eine alternative Domain für die primäre Domain. Wenn also alias.example.com als Aliasdomain eingerichtet ist, beziehen sich johndoe@example.com und johndoe@alias.example.com auf dasselbe Konto. Eine Aliasdomain kann nur für die primäre Domain einen alternativen Namen bereitstellen. Für sekundäre Domains lassen sich keine Aliasdomains hinzufügen.

Alle Domains müssen die folgenden Voraussetzungen erfüllen:

  • Sie müssen gültige, globale DNS-Domainnamen sein. Während der Einrichtung benötigen Sie unter Umständen Administratorzugriff auf die entsprechenden DNS-Zonen, um die Domaininhaberschaft zu bestätigen.
  • Eine Domain wie example.com kann nur auf ein einzelnes Verzeichnis verweisen. Sie können jedoch verschiedene Subdomains wie subdomain.example.com verwenden, um andere Verzeichnisse zu referenzieren.
  • Primäre und sekundäre Domains müssen einen gültigen MX-Eintrag haben. Damit ist die ordnungsgemäße Zustellung von Nachrichten gewährleistet, die an E-Mail-Adressen gesendet werden, die mit dem jeweiligen Domainnamen gebildet wurden.

DNS-Domains in Azure AD verwenden

Cloud Identity verwendet das DNS auf ähnliche Weise wie Azure AD. Hier wird das DNS herangezogen, um Azure AD-Mandanten zu unterscheiden und Nutzernamen mit Mandanten zu verknüpfen. Zwei nennenswerte Unterschiede sollten Sie jedoch beachten:

  1. Anfangsdomains: Wenn Sie einen Azure AD-Mandanten erstellen, wird er einer Anfangsdomain zugeordnet, die eine Subdomain von onmicrosoft.com ist. Diese Domain unterscheidet sich insofern von jedem selbst registrierten benutzerdefinierten Domainnamen, dass Sie nicht Inhaber der Domain sind und keinen Administratorzugriff auf die entsprechende DNS-Zone haben.

    In Cloud Identity gibt es kein Äquivalent für eine Anfangsdomain. Vielmehr müssen Sie Inhaber aller Domains sein, die Sie einem Cloud Identity-Konto zuordnen. Diese Voraussetzung bedeutet, dass Sie eine Subdomain von onmicrosoft.com nicht als Cloud Identity-Domain registrieren können.

  2. In Nutzerkennzeichnungen verwendete Domains: Azure AD unterscheidet zwischen E-Mail-Adressen vom Typ MOERA (Microsoft Online Email Routing Address) und UPNs. Beide haben das RFC 822-Format (user@domain), dienen jedoch unterschiedlichen Zwecken: Während UPNs zum Identifizieren von Nutzern und in Anmeldeformularen verwendet werden, erfolgt die Zustellung von E-Mails ausschließlich über MOERAs.

    Das von UPNs verwendete Domainsuffix muss mit einer der registrierten Domains Ihres Azure AD-Mandanten übereinstimmen. Diese Voraussetzung gilt nicht für E-Mail-Adressen.

    Das Konzept eines UPNs spielt in Cloud Identity keine Rolle. Stattdessen wird die E-Mail-Adresse eines Nutzers als Kennzeichnung verwendet. Folglich muss die von der E-Mail-Adresse verwendete Domain mit einer der registrierten Domains des Cloud Identity-Kontos übereinstimmen.

Azure AD und Cloud Identity können dieselben DNS-Domains verwenden. In Anbetracht der beiden oben beschriebenen Unterschiede sollten Sie Ihre Domainzuordnung darauf abstimmen, wie Sie Nutzerkonten zwischen Azure AD und Cloud Identity zuordnen möchten.

Nutzerkonten zuordnen

Der dritte Faktor, den Sie beim Verbinden von Active Directory mit Google Cloud berücksichtigen sollten, ist die Zuordnung von Nutzerkonten zwischen Azure AD und Cloud Identity.

Für die erfolgreiche Zuordnung zwischen Azure AD- und Cloud Identity-Konten sind für jedes Konto zwei Informationen erforderlich:

  1. Eine stabile, eindeutige ID, mit der Sie während der Synchronisierung verfolgen können, welches Azure AD-Konto welchem Cloud Identity-Konto entspricht.
  2. Eine E-Mail-Adresse, deren Domainteil einer primären, sekundären oder Aliasdomain von Cloud Identity entspricht. Da diese E-Mail-Adresse überall in Google Cloud verwendet wird, muss sie menschenlesbar sein.

Azure AD identifiziert Nutzer intern anhand der ObjectId, einer zufällig generierten, global eindeutigen ID. Während diese ID stabil ist und daher die erste Voraussetzung erfüllt, ist sie für Menschen nichtssagend und nicht mit dem Format einer E-Mail-Adresse konform. Der UPN oder die E-Mail-Adresse sind daher die einzigen praktikablen Möglichkeiten, um Nutzer zuzuordnen.

Nutzerkonten nach E-Mail-Adresse zuordnen

Wenn der Nutzer eine E-Mail-Adresse eingibt, die zu einem Cloud Identity-Konto gehört, das für die Einmalanmeldung mit Azure AD konfiguriert ist, wird der Nutzer zum Azure AD-Anmeldebildschirm weitergeleitet.

Azure AD verwendet UPNs anstelle von E-Mail-Adressen, um Nutzer zu identifizieren. Daher wird der Nutzer im Anmeldebildschirm aufgefordert, einen UPN anzugeben.

Anmeldebildschirm, der zur Eingabe eines UPN auffordert

Wenn der Azure AD-Mandant so konfiguriert ist, dass AD FS für die Anmeldung zu verwenden ist, wird der Nutzer noch einmal weitergeleitet, diesmal zum AD FS-Anmeldebildschirm. AD FS kann Nutzer entweder anhand ihres Active Directory-UPNs oder ihres Anmeldenamens identifizieren, der vor Windows 2000 gültig war (domain\user).

AD FS-Anmeldebildschirm

Wenn die für Cloud Identity verwendete E-Mail-Adresse, der von Azure AD verwendete UPN und der von Active Directory verwendete UPN unterschiedlich sind, können die aufeinanderfolgenden Anmeldebildschirme den Endnutzer leicht verwirren. Sind dagegen alle drei Kennzeichnungen wie in den Beispielscreenshots identisch (johndoe@example.com), bleibt Nutzern diese potenzielle Verwirrung erspart, da die technischen Unterschiede zwischen UPNs und E-Mail-Adressen nicht ersichtlich sind.

Nach UPN zuordnen

Was die Nutzerfreundlichkeit anbelangt, so ist die Zuordnung von Azure AD-UPNs zu E-Mail-Adressen in Cloud Identity wahrscheinlich die beste Option. Ein weiterer Vorteil von UPNs ist, dass Azure AD Eindeutigkeit garantiert, sodass Sie das Risiko von Namenskonflikten vermeiden.

Damit Sie aber die Zuordnung zwischen Azure AD-UPNs und E-Mail-Adressen in Cloud Identity vornehmen können, müssen folgende Voraussetzungen erfüllt sein:

  • Die Azure AD-UPNs müssen gültige E-Mail-Adressen sein, damit alle von Google Cloud gesendeten Benachrichtigungs-E-Mails korrekt an das Postfach des Nutzers zugestellt werden. Wenn dies nicht bereits der Fall ist, können Sie unter Umständen Alias-E-Mail-Adressen konfigurieren und somit gewährleisten, dass der Nutzer solche E-Mails erhält.
  • Die UPNs von allen relevanten Nutzern in Azure AD müssen eine benutzerdefinierte Domain als Suffix verwenden ([user]@[custom-domain]). UPNs mit der Azure AD-Anfangsdomain ([user]@[tenant].onmicrosoft.com) können E-Mail-Adressen in Cloud Identity nicht zugeordnet werden, da nicht Sie der Inhaber dieser Anfangsdomain sind, sondern Microsoft.
  • Alle benutzerdefinierten Domains, die von Azure AD für UPNs verwendet werden, müssen auch in Cloud Identity registriert sein. Das bedeutet, dass Sie Zugriff auf die jeweiligen DNS-Zonen haben müssen, um die Domain zu bestätigen. Damit vorhandene TXT-DNS-Einträge, die Sie zur Bestätigung der Domaininhaberschaft in Azure AD unter Umständen erstellt haben, nicht überschrieben werden, können Sie einen CNAME-Eintrag zum Bestätigen der Domaininhaberschaft in Cloud Identity verwenden.

Für Cloud Identity spielt es keine Rolle, ob die UPNs in Active Directory mit den UPNs in Azure AD übereinstimmen. Bei Verwendung von AD FS ist es für den Nutzer jedoch einfacher, wenn die UPNs in Active Directory und Azure AD identisch sind.

Nutzer nach E-Mail-Adresse zuordnen

Falls die Zuordnung von Azure AD-UPNs zu E-Mail-Adressen von Cloud Identity nicht in Betracht kommt, können Sie Konten auch nach E-Mail-Adresse zuordnen.

Wenn Sie eine E-Mail-Adresse in Active Directory angeben, wird diese im mail-Attribut des jeweiligen user-Objekts gespeichert. Azure AD Connect synchronisiert den Wert mit dem Mail-Attribut in Azure AD. Außerdem stellt Azure AD das Attribut für die Nutzerverwaltung zur Verfügung, sodass Sie es der E-Mail-Adresse in Cloud Identity zuordnen können.

Wichtig ist, dass das Mail-Attribut von Azure AD derzeit nicht im Azure-Portal angezeigt wird und nur über APIs oder PowerShell aufgerufen und bearbeitet werden kann. Obwohl Sie auf der Benutzeroberfläche eine E-Mail-Adresse und eine alternative E-Mail-Adresse angeben können, werden diese Werte nicht im Mail-Attribut gespeichert, sodass sie nicht für die Bereitstellung in Cloud Identity verwendet werden können. Aus diesem Grund ist die Zuordnung von Nutzern nach E-Mail-Adresse nur dann sinnvoll, wenn Sie Ihre Nutzer hauptsächlich in Active Directory und nicht in Azure AD erstellen und bearbeiten.

Für die Zuordnung von Nutzern nach E-Mail-Adresse müssen die folgenden zusätzlichen Voraussetzungen erfüllt sein:

  • Die E-Mail-Zuweisung muss abgeschlossen sein. Allen zu synchronisierenden Nutzerkonten muss eine E-Mail-Adresse zugewiesen sein. Das ist vor allem dann nicht immer der Fall, wenn Nutzer aus einem lokalen Active Directory synchronisiert werden, da mail ein optionales Nutzerattribut in Active Directory ist. Nutzer, die keine E-Mail-Adresse im Mail-Attribut von Azure AD haben, werden während der Synchronisierung unbemerkt ignoriert.
  • E-Mail-Adressen müssen im gesamten Azure AD-Mandanten eindeutig sein. Obwohl Active Directory bei der Kontoerstellung nicht auf Eindeutigkeit prüft, erkennt Azure AD Connect Konflikte standardmäßig. Dies kann dazu führen, dass die Synchronisierung von betroffenen Nutzerkonten fehlschlägt.
  • Die von E-Mail-Adressen verwendeten Domains müssen nicht in Azure AD registriert sein, dafür aber in Cloud Identity. Diese Voraussetzung bedeutet, dass Sie zur Domainbestätigung Zugriff auf die entsprechenden DNS-Zonen haben müssen und keine E-Mail-Adressen mit Domains verwenden können, deren Inhaber Sie nicht sind (z. B. gmail.com).

Gruppen zuordnen

Der vierte Faktor, den Sie vor dem Verbinden von Active Directory mit Google Cloud berücksichtigen sollten, ist die Synchronisierung und Zuordnung von Gruppen zwischen Active Directory und Google Cloud.

In Google Cloud werden Gruppen oft eingesetzt, um eine effiziente projektübergreifende Zugriffsverwaltung zu ermöglichen. Statt in jedem Projekt Cloud IAM-Rollen (Cloud Identity and Access Management) an einzelne Nutzer zu vergeben, legen Sie verschiedene Gruppen fest, die allgemeine Rollen in Ihrer Organisation abbilden. Anschließend ordnen Sie diese Gruppen einer Reihe von Cloud IAM-Rollen zu. Über die Gruppen können Sie den Nutzerzugriff auf unterschiedliche Ressourcen steuern.

Das Zuordnen von Gruppen zwischen Azure AD und Google Cloud ist optional. Nachdem Nutzerkonten verbunden wurden, können Sie Gruppen direkt in Cloud Identity erstellen und verwalten. Das bedeutet, dass Active Directory oder Azure AD das zentrale System für die Identitätsverwaltung bleibt, nicht jedoch für die Google Cloud-Zugriffsverwaltung.

Wenn Sie Active Directory oder Azure AD als zentrales System für die Identitäts- und Zugriffsverwaltung verwenden möchten, sollten Sie Gruppen aus Azure AD synchronisieren, statt sie in Cloud Identity zu verwalten. Bei diesem Ansatz können Sie Cloud IAM so einrichten, dass Sie den Zugriff auf Ressourcen in Google Cloud mithilfe von Gruppenmitgliedschaften in Azure AD steuern können.

Gruppen in Cloud Identity

In Cloud Identity gibt es nur einen Gruppentyp. Gruppen sind in Cloud Identity nicht auf den Bereich des Cloud Identity-Kontos beschränkt, in dem sie definiert wurden. Stattdessen können Gruppen Nutzerkonten aus verschiedenen Cloud Identity-Konten enthalten, in anderen Cloud Identity-Konten referenziert und verschachtelt werden sowie in jeder Google Cloud-Organisation zum Einsatz kommen.

Wie Nutzerkonten werden Gruppen in Cloud Identity anhand der E-Mail-Adresse identifiziert. Die E-Mail-Adresse muss keinem tatsächlichen Postfach entsprechen, jedoch eine der Domains verwenden, die für das jeweilige Cloud Identity-Konto registriert sind.

Wenn Sie mit Gruppen in Cloud IAM arbeiten, müssen Sie diese häufig anhand ihrer E-Mail-Adresse statt ihres Namens angeben. Daher sollten Gruppen nicht nur einen aussagekräftigen Namen, sondern auch eine aussagekräftige und wiedererkennbare E-Mail-Adresse haben.

Gruppen in Azure AD

Azure AD unterstützt mehrere Gruppentypen, die jeweils auf unterschiedliche Anwendungsfälle ausgelegt sind. Gruppen beziehen sich auf einen einzelnen Mandanten und werden durch eine zufällig generierte, global eindeutige Objekt-ID identifiziert. Gruppen können verschachtelt sein und entweder Nutzer aus demselben Mandanten enthalten oder Nutzer, die von anderen Mandanten über Azure B2B eingeladen wurden. Azure AD unterstützt auch dynamische Gruppen, deren Mitglieder automatisch anhand einer Abfrage bestimmt werden.

Bei der Einbindung von Azure AD in Cloud Identity sind vor allem zwei Attribute von Gruppen interessant – ob sie für E-Mails aktiviert sind und ob sie für Sicherheit aktiviert sind:

  • Mit einer für Sicherheit aktivierten Gruppe kann der Zugriff auf Ressourcen in Azure AD verwaltet werden. Jede für Sicherheit aktivierte Gruppe ist daher im Kontext von Google Cloud potenziell relevant.
  • Eine für E-Mails aktivierte Gruppe hat eine E-Mail-Adresse. Dies ist wichtig, da Gruppen in Cloud Identity anhand von E-Mail-Adressen identifiziert werden.

In Azure AD können Sie Gruppen vom Typ "Sicherheit" oder "Office 365" (manchmal auch einheitliche Gruppen genannt) erstellen. Wenn Sie Gruppen aus einem lokalen Active Directory synchronisieren oder den Typ "Office 365" verwenden, lassen sich auch Gruppen des Typs "Verteilerliste" erstellen.

In der folgenden Tabelle werden die Unterschiede zwischen diesen verschiedenen Arten von Gruppen zusammengefasst. Sie sehen, ob eine Gruppe für E-Mails oder Sicherheit aktiviert ist und welchem Active Directory-Gruppentyp sie in einer Azure AD Connect-Standardkonfiguration zugeordnet wird:

Quelle Active Directory-Gruppentyp Azure AD-Gruppentyp Für E-Mails aktiviert Für Sicherheit aktiviert
Azure AD - Office 365-Gruppe Immer Optional
Azure AD - Sicherheitsgruppe Optional Immer
Lokal Sicherheitsgruppe (mit E-Mail) Sicherheitsgruppe Ja Ja
Lokal Sicherheitsgruppe (ohne E-Mail) Sicherheitsgruppe Nein Ja
Lokal Verteilerliste (mit E-Mail) Verteilerliste Ja Nein
Lokal Verteilerliste (ohne E-Mail) (von Azure AD Connect ignoriert)

Anders als bei Nutzern setzt Azure AD bei Gruppen voraus, dass ihre zugewiesenen E-Mail-Adressen eine Domain verwenden, die als benutzerdefinierte Domain in Azure AD registriert wurde. Diese Voraussetzung führt zu folgendem Standardverhalten:

  • Wenn eine Gruppe in Active Directory eine E-Mail-Adresse mit einer Domain hat, die bereits in Azure AD registriert ist, wird die E-Mail-Adresse während der Synchronisierung mit Azure AD korrekt verwaltet.
  • Wenn eine Gruppe in Active Directory eine E-Mail-Adresse hat, die nicht in Azure AD registriert wurde, generiert Azure AD während der Synchronisierung automatisch eine neue E-Mail-Adresse. Diese E-Mail-Adresse verwendet die Standarddomain des Mandanten. Wenn Ihr Mandant die Anfangsdomain als Standarddomain verwendet, hat die resultierende E-Mail-Adresse das Format [name]@[tenant].onmicrosoft.com.
  • Wenn Sie eine Office 365-Gruppe in Azure AD erstellen, generiert Azure AD ebenfalls automatisch eine E-Mail-Adresse, die die Standarddomain des Mandanten verwendet.

Gruppenidentitäten zuordnen

Für eine erfolgreiche Zuordnung von Azure AD-Gruppen zu Cloud Identity-Gruppen ist eine gemeinsame Kennzeichnung erforderlich. Cloud Identity setzt voraus, dass diese Kennzeichnung eine E-Mail-Adresse ist. Damit haben Sie in Azure AD zwei Möglichkeiten:

  • Sie können die E-Mail-Adresse einer Gruppe in Azure AD verwenden und einer E-Mail-Adresse in Cloud Identity zuordnen.
  • Sie können eine E-Mail-Adresse vom Namen der Gruppe in Azure AD ableiten und die resultierende Adresse einer E-Mail-Adresse in Cloud Identity zuordnen.

Nach E-Mail-Adresse zuordnen

Das Zuordnen von Gruppen nach E-Mail-Adresse ist die offensichtlichste Wahl, obwohl dafür mehrere Voraussetzungen zu erfüllen sind:

  • Alle zu synchronisierenden Gruppen müssen eine E-Mail-Adresse haben. In der Praxis bedeutet dies, dass Sie nur Gruppen synchronisieren können, die für E-Mails aktiviert sind. Gruppen ohne E-Mail-Adresse werden bei der Bereitstellung ignoriert.
  • Die E-Mail-Adressen müssen im gesamten Mandanten eindeutig sein. Da Azure AD die Eindeutigkeit nicht erzwingt, müssen Sie dafür unter Umständen benutzerdefinierte Prüfungen oder Richtlinien implementieren.
  • Die von E-Mail-Adressen verwendeten Domains müssen sowohl in Azure AD als auch in Cloud Identity registriert sein. Alle Gruppen, deren E-Mail-Adressen Domains verwenden, die nicht in Cloud Identity registriert sind (z. B. die Domain [tenant].onmicrosoft.com), werden nicht synchronisiert.

Wenn alle relevanten Gruppen diese Kriterien erfüllen, prüfen Sie, ob die von den E-Mail-Adressen verwendeten Domains in der Liste der in Cloud Identity registrierten DNS-Domains enthalten sind.

Nach Name zuordnen

Manchmal ist es nicht einfach, die Kriterien für die Zuordnung von Gruppen nach E-Mail-Adresse zu erfüllen. Dies trifft vor allem dann zu, wenn viele der in Cloud Identity bereitzustellenden Sicherheitsgruppen nicht für E-Mails aktiviert sind. In diesem Fall kann es besser sein, eine E-Mail-Adresse automatisch aus dem Anzeigenamen der Gruppe abzuleiten.

Das Ableiten einer E-Mail-Adresse bringt zwei Probleme mit sich:

  1. Eine E-Mail-Adresse, die vom Namen einer Gruppe abgeleitet ist, kann sich mit der E-Mail-Adresse eines Nutzers überschneiden.
  2. Azure AD erzwingt keine Eindeutigkeit für Gruppennamen. Wenn mehrere Gruppen in Ihrem Azure AD-Mandanten denselben Namen haben, überschneiden sich die von diesem Namen abgeleiteten E-Mail-Adressen, sodass nur eine Gruppe erfolgreich synchronisiert wird.

Zur Lösung des ersten Problems können Sie eine Domain für die generierte E-Mail-Adresse verwenden, die sich von den Domains unterscheidet, die von Nutzern verwendet werden. Wenn beispielsweise alle Nutzer E-Mail-Adressen mit example.com als Domain verwenden, könnten Sie groups.example.com für alle Gruppen verwenden. Für die Registrierung von Subdomains in Cloud Identity ist keine Domainbestätigung erforderlich, sodass die DNS-Zone groups.example.com nicht einmal existieren muss.

Das zweite Problem der doppelten Gruppennamen können Sie nur technisch beheben. Dazu leiten Sie die E-Mail-Adresse der Gruppe von der Objekt-ID ab. Da die resultierenden Gruppennamen ziemlich kryptisch und schwer zu handhaben sind, sollten Sie doppelte Gruppennamen in Azure AD identifizieren und umbenennen, bevor Sie die Bereitstellung für Cloud Identity einrichten.

Lebenszyklus von Nutzerkonten verwalten

Wenn Sie die richtige Zuordnung zwischen Mandanten, Domains, Nutzern und Gruppen gefunden haben, können Sie die Verwaltung von Nutzerkonten und -gruppen in Cloud Identity automatisieren. Allerdings stellt sich die Frage, für welche Nutzerkonten und -gruppen die Einmalanmeldung (SSO) bereitgestellt und aktiviert werden sollte.

Onboarding

Je nachdem, wie Sie Google Cloud verwenden möchten, könnte jeder Nutzer, der ein Konto in Azure AD hat oder für den ein neues Konto erstellt wird, auch die Zugriffsberechtigung für Google Cloud erhalten. Wahrscheinlicher ist jedoch, dass nur ein Teil Ihrer Nutzer in der Lage sein muss, auf Google Cloud zuzugreifen. Daher soll hier zwischen vier Gruppen von Nutzerkonten in Azure AD unterschieden werden:

  • Konten in Azure AD: Die Gesamtzahl der Konten in Azure AD.
  • Für Cloud Identity bereitgestellte Konten: Die Teilmenge der Azure AD-Konten, die zur Bereitstellung für Cloud Identity zugewiesen wurden.
  • Für SSO aktivierte Konten: Die Teilmenge der Azure AD-Konten, die für die Einmalanmeldung (SSO) zugewiesen wurden.
  • Konten mit erteiltem Zugriff in Cloud IAM: Die Teilmenge der für Cloud Identity bereitgestellten Azure AD-Konten, denen Zugriff auf alle Google Cloud-Ressourcen gewährt wurde.

Zur Verwendung von Google Cloud-Ressourcen muss ein Konto für Cloud Identity bereitgestellt und für SSO aktiviert sein. Außerdem muss dem Konto Zugriff in Cloud IAM gewährt werden.

Ein für Cloud Identity bereitgestelltes und für SSO aktiviertes Konto, dem in Cloud IAM kein Zugriff gewährt wurde, kann zwar Google Cloud nicht verwenden, jedoch unter Umständen andere Google-Tools wie Data Studio.

Ein für Cloud Identity bereitgestelltes Konto, das nicht für SSO aktiviert wurde, ist für den Nutzer praktisch nutzlos, da er sich damit nicht anmelden kann. Allerdings verhindert das Vorhandensein des Kontos in Cloud Identity, dass der Nutzer seine Unternehmens-E-Mail-Adresse zur Anmeldung für ein Privatnutzerkonto bei YouTube, der Google-Suche oder auf anderen Google-Websites verwendet. Mitarbeitern die Nutzung von Privatnutzerkonten für Geschäftszwecke zu gestatten, kann riskant sein, da Ihr Unternehmen das Konto, seinen Lebenszyklus und seine Sicherheit nicht steuert. Die Blockierung der Anmeldung könnte also in Ihrem Interesse sein.

Die Aktivierung eines Kontos für SSO ohne Bereitstellung des Kontos für Cloud Identity ist nützlich, wenn Sie vorhandene Nutzerkonten zu Cloud Identity migrieren. Abgesehen von einer Migration besteht wenig Anlass, SSO für ein Konto zu aktivieren, das nicht auch für Cloud Identity bereitgestellt wird.

SSO für alle Konten bereitstellen und aktivieren

In Anbetracht des Zusammenspiels dieser vier Nutzergruppen besteht der einfachste Ansatz darin, alle Azure AD-Konten für Cloud Identity bereitzustellen und SSO für sämtliche Konten zu aktivieren. Dabei wird aber nur einer relevanten Teilmenge von Nutzern Zugriff auf Ressourcen gewährt:

SSO für alle Konten bereitstellen und aktivieren

In größeren Organisationen empfiehlt es sich, Berechtigungen auf Basis von Gruppen zu gewähren, nicht Einzelpersonen. Die für diesen Zweck verwendeten Gruppen können entweder in Cloud Identity erstellt oder aus Azure AD bereitgestellt worden sein.

Wenn Sie mit Cloud Identity Gruppen erstellen und verwalten, um den Zugriff auf Google Cloud-Ressourcen zu steuern, ergibt sich der Vorteil, dass alle Nutzerkonten in Cloud Identity sofort verfügbar sind, wenn Sie mehr Nutzern Zugriff auf eine Gruppe gewähren möchten. Ansonsten müssten Sie vielleicht erst Änderungen in Azure AD vornehmen, die Synchronisierung des Nutzerkontos abwarten und dann weitere Schritte in Cloud Identity ausführen, um einem Nutzer Zugriff auf Google Cloud zu gewähren.

SSO für die kleinste Gruppe von Konten bereitstellen und aktivieren

Wenn Sie alle Azure AD-Konten für Cloud Identity bereitstellen und dafür SSO aktivieren, bedeutet das, dass alle Nutzer auf Google Cloud-fremde Tools wie Data Studio zugreifen können, was vielleicht nicht nötig wäre. Ein alternativer Ansatz besteht darin, nur die kleinstmögliche Gruppe von Konten für Cloud Identity bereitzustellen. Idealerweise enthält diese Gruppe dann nur die Konten, denen auch in Cloud IAM Zugriff gewährt wurde.

SSO für die kleinste Gruppe von Konten bereitstellen und aktivieren

Wenn Sie Gruppen zur Zugriffsverwaltung verwenden, diese Gruppen aber lieber in Azure AD statt in Cloud Identity verwalten möchten, können Sie dieselben Gruppen verwenden, mit denen Sie auch die Zuweisung zu den jeweiligen Unternehmensanwendungen steuern. Damit ist gewährleistet, dass nur relevante Konten bereitgestellt werden. Alternativ können Sie auch eine dynamische Gruppe in Azure AD erstellen und sich damit der Gruppe von Konten annähern, die potenziell Zugriff auf Google Cloud benötigen.

Ein Nachteil dieses Ansatzes ist, dass sich Nutzer, deren Konten nicht bereitgestellt werden, noch immer für ein Privatnutzerkonto über ihre Unternehmens-E-Mail-Adresse anmelden können.

Alle Nutzer bereitstellen und SSO für die kleinste Gruppe von Konten aktivieren

Den Nachteil des vorherigen Ansatzes können Sie wettmachen, wenn Sie alle Konten für Cloud Identity bereitstellen, SSO jedoch nur für diejenigen Nutzer aktivieren, denen auch Zugriff in Cloud IAM gewährt werden soll.

Alle Nutzer bereitstellen und SSO für die kleinste Gruppe von Konten aktivieren

Dieser Ansatz verhindert, dass Privatnutzerkonten erstellt werden und sich mehr Nutzer als nötig bei Google-Diensten anmelden können.

Offboarding

Nutzern Zugriff auf Google Cloud zu gewähren, wenn sie ihn benötigen, ist genauso wichtig, wie Nutzern diesen Zugriff wieder zu entziehen, wenn sie das Unternehmen verlassen oder die Rollen wechseln. Wird ein Nutzer in Azure AD gelöscht, schlagen nachfolgende Einmalanmeldungen für diesen Nutzer fehl. Außerdem wird das entsprechende Nutzerkonto in Cloud Identity gesperrt.

Ähnlich verhält es sich, wenn Sie einen Nutzer aus einer Gruppe entfernen, die mit Cloud Identity synchronisiert wird. In diesem Fall wird die Entfernung dieser Mitgliedschaft in Cloud Identity übernommen, wodurch der Nutzer wiederum alle Berechtigungen verliert, die der Gruppe zugeordnet sind.

Weitere Informationen