Google Cloud Platform mit Active Directory verbinden: Einführung

Dieser Artikel ist der erste Teil einer mehrteiligen Reihe, in der erläutert wird, wie eine vorhandene Active Directory-basierte Identitätsverwaltungslösung auf die Google Cloud Platform (GCP) erweitert werden kann. In diesem Artikel wird beschrieben, wie Sie konsistente Authentifizierungs- und Autorisierungsmechanismen in einer hybriden Computerumgebung einrichten. Der Schwerpunkt des Artikels liegt auf der Verwendung von Cloud Identity, während sich manche der beschriebenen Inhalte auf die G Suite beziehen.

Die Reihe besteht aus folgenden Teilen:

IT-Abteilungen von Unternehmen sind häufig auf Active Directory angewiesen, um Nutzerkonten zu verwalten und den Zugriff auf Anwendungen und Rechenressourcen zu steuern. Diese Abhängigkeit macht Active Directory zu einem grundlegenden Teil ihrer IT-Landschaft und der lokalen Infrastruktur.

Wenn Sie eine vorhandene IT-Landschaft im Rahmen einer Hybridstrategie auf die GCP erweitern, sollten Sie Identitäten an einem zentralen Punkt verwalten. Mit einer einzigen Identitätsverwaltungslösung können Sie den Verwaltungsaufwand auf ein Minimum reduzieren und dafür sorgen, dass Nutzer und Anwendungen sich in einer Hybridumgebung sicher authentifizieren können.

In diesem Artikel werden die logischen Strukturen von Active Directory und der GCP verglichen. Außerdem wird erläutert, wie Sie Active Directory-Konten Nutzer- und Gruppenkonten in der GCP zuordnen können, um einen Verbund zu implementieren. Am Ende des Artikels können Sie anhand eines Flussdiagramms den besten Ansatz für die Zuordnung zwischen Active Directory und der GCP in Ihrem Szenario ermitteln.

In diesem Artikel wird vorausgesetzt, dass Sie mit Active Directory vertraut sind.

Verbund implementieren

In der GCP werden für die Authentifizierung und Zugriffsverwaltung Google-Identitäten verwendet. Für den Zugriff auf GCP-Ressourcen muss ein Mitarbeiter eine Google-Identität haben. Die manuelle Verwaltung der Google-Identitäten jedes Mitarbeiters wäre umständlich, wenn alle Mitarbeiter bereits ein Konto in Active Directory haben. Durch das Verbinden von Nutzeridentitäten zwischen Active Directory und der GCP können Sie die Verwaltung von Google-Konten automatisieren und ihren Lebenszyklus an die Konten in Active Directory binden. Durch den Verbund wird Folgendes gewährleistet:

  • Active Directory bleibt die einzige Datenquelle für die Identitätsverwaltung.
  • Für alle Nutzerkonten in Active Directory oder für eine ausgewählte Teilmenge wird automatisch ein Google-Konto erstellt.
  • Wenn ein Konto in Active Directory 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.
  • Active Directory verwaltet die Nutzerauthentifizierung. Sie müssen also keine Passwörter mit der GCP synchronisieren.

Auf Google-Seite können Sie Cloud Identity verwenden, um ein Verzeichnis für private Nutzerkonten einzurichten, in dem Sie Google-Konten erstellen und verwalten können. Der Verbund von Active Directory mit Cloud Identity beinhaltet zwei Teile:

Active Directory mit Cloud Identity verbinden

  • Konten synchronisieren: Relevante Nutzerkonten und -gruppen werden regelmäßig von Active Directory nach Cloud Identity synchronisiert. Dadurch wird sichergestellt, dass ein in Active Directory neu erstelltes Konto in der GCP referenziert werden kann, noch bevor sich der verknüpfte Nutzer zum ersten Mal angemeldet hat. Außerdem wird durch diesen Vorgang gewährleistet, dass Kontoentfernungen weitergegeben werden.

    Die Synchronisierung erfolgt in eine Richtung. Änderungen in Active Directory werden also in Cloud Identity repliziert, umgekehrt gilt dies jedoch nicht. Außerdem werden bei der Synchronisierung keine Passwörter berücksichtigt. In einem Verbund bleibt Active Directory das einzige System, das diese Anmeldeinformationen verwaltet.

  • Einmalanmeldung (SSO): Wenn ein Nutzer sich bei der GCP authentifizieren muss, delegiert Cloud Identity die Authentifizierung mithilfe des SAML-Protokolls (Security Assertion Markup Language) an Active Directory. Durch diese Übertragung wird sichergestellt, dass Nutzeranmeldeinformationen nur in Active Directory verwaltet und geltende Richtlinien oder MFA-Mechanismen (Multi-Faktor-Authentifizierung) durchgesetzt werden. Damit eine Anmeldung durchgeführt werden kann, muss das entsprechende Konto jedoch zuvor synchronisiert worden sein.

Zum Implementieren eines Verbunds können Sie die folgenden Tools verwenden:

  • Google Cloud Directory Sync ist ein von Google bereitgestelltes kostenloses Tool, mit dem der Synchronisierungsprozess implementiert wird. Cloud Directory Sync kommuniziert per SSL (Secure Socket Layer) mit der Google Identity Platform und wird normalerweise in der vorhandenen Computerumgebung ausgeführt.
  • Active Directory Federation Services (AD FS) wird von Microsoft als Teil von Windows Server bereitgestellt. Mit AD FS können Sie Active Directory für die Verbundauthentifizierung verwenden. AD FS wird normalerweise in der vorhandenen Computerumgebung ausgeführt.

Da APIs für die Google Identity Platform öffentlich verfügbar sind und SAML ein offener Standard ist, stehen viele Tools zur Verfügung, um einen Verbund zu implementieren. Der Schwerpunkt dieses Artikels liegt auf der Verwendung von Cloud Directory Sync und AD FS.

Logische Struktur von Active Directory

Die Komponente der obersten Ebene in einer Active Directory-Infrastruktur ist die Gesamtstruktur. Sie dient als Container für eine oder mehrere Domains und ihr Name wird von der Stammdomain der Gesamtstruktur abgeleitet. Domains in einer Active Directory-Gesamtstruktur stehen in einem wechselseitigen Vertrauensverhältnis zueinander. Nutzer, die in einer Domain authentifiziert sind, können auf Ressourcen zugreifen, die sich in einer anderen Domain befinden. Wenn Gesamtstrukturen nicht über gesamtstrukturübergreifende Vertrauensstellungen miteinander verbunden sind, besteht zwischen separaten Gesamtstrukturen standardmäßig kein Vertrauen. Nutzer, die in einer Gesamtstruktur authentifiziert sind, können dann nicht auf Ressourcen zugreifen, die sich in einer anderen Gesamtstruktur befinden.

Active Directory-Infrastruktur

Active Directory-Domains sind Container für die Verwaltung von Ressourcen und gelten als administrative Grenzen. Mehrere Domains in einer Gesamtstruktur bieten die Möglichkeit, die Verwaltung zu vereinfachen oder zusätzliche Strukturen durchzusetzen, doch Domains in einer Gesamtstruktur stellen keine Sicherheitsgrenzen dar.

Logische Struktur der GCP

In der GCP werden Ressourcen in Organisationen verwaltet, die Sie mithilfe von Ordnern und Projekten zusätzlich segmentieren können. Organisationen, Ordner und Projekte haben daher einen ähnlichen Zweck wie Active Directory-Domains.

Active Directory behandelt Nutzerkonten als Ressourcen, sodass die Nutzerkontenverwaltung und -authentifizierung an Domains gebunden ist. In der GCP hingegen werden Nutzerkonten, abgesehen von Dienstkonten, nicht in einer Organisation verwaltet. Stattdessen wird in der GCP Cloud Identity oder G Suite verwendet, um Nutzerkonten zu verwalten.

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

GCP-Identitätsinfrastruktur

Ähnlich wie eine Gesamtstruktur und eine Gesamtstruktur-Stammdomain in Active Directory, die immer zusammen erstellt werden, wird ein Cloud Identity-Konto immer parallel zu einer GCP-Organisation erstellt. Und genauso wie eine Gesamtstruktur-Stammdomain und eine Gesamtstruktur den gleichen Namen haben und nicht voneinander getrennt werden können, tragen das Cloud Identity-Konto und die GCP-Organisation denselben Namen und sind miteinander verbunden. Eine GCP-Organisation darf jedoch auf Nutzer und Gruppen aus zusätzlichen Cloud Identity-Konten verweisen.

Active Directory und die GCP verknüpfen

Trotz gewisser Ähnlichkeiten zwischen der logischen Struktur von Active Directory und der GCP gibt es keine Zuordnung zwischen den beiden Strukturen, die in jedem Szenario gleich gut funktioniert. Der richtige Ansatz für die Verknüpfung der beiden Systeme und die Zuordnung der Struktur hängt von mehreren Faktoren ab:

  • Zuordnung von Domains und Gesamtstrukturen zu Cloud Identity-Konten
  • Zuordnung von DNS-Domains
  • Zuordnung von Nutzerkonten
  • Zuordnung von Gruppen

In den folgenden Abschnitten wird individuell auf diese Faktoren eingegangen.

Gesamtstrukturen zuordnen

Besonders in größeren Organisationen wird oft mehr als eine Active Directory-Domain eingesetzt, um Identitäten und den unternehmensweiten Zugriff zu verwalten. Wenn Sie Active Directory mit der GCP verbinden möchten, sollten Sie zuerst die Topologie Ihrer Active Directory-Infrastruktur prüfen.

Eine Gesamtstruktur, eine Domain

Eine Gesamtstruktur, eine Domain

Wenn eine Gesamtstruktur nur eine Domain enthält, können Sie die ganze Active Directory-Gesamtstruktur einem einzelnen Cloud Identity-Konto zuordnen. Dieses Konto bietet dann die Basis für eine einzelne GCP-Organisation, die Sie zur Verwaltung Ihrer GCP-Ressourcen verwenden können.

In einer Umgebung mit einer Domain können Sie sowohl über Domaincontroller als auch über globale Katalogserver auf alle Objekte zugreifen, die in Active Directory verwaltet werden. In den meisten Fällen können Sie eine einzige Instanz von Cloud Directory Sync ausführen, um Nutzerkonten und -gruppen mit der GCP zu synchronisieren, und eine einzelne AD FS-Instanz oder -Flotte zur Verarbeitung der Einmalanmeldung (SSO) einsetzen.

Eine Gesamtstruktur, mehrere Domains

Eine Gesamtstruktur, mehrere Domains

Wenn eine Gesamtstruktur mehrere Active Directory-Domains enthält, können Sie diese in einer oder mehreren Domainstrukturen organisieren. In beiden Fällen können Sie die ganze Gesamtstruktur einem einzigen Cloud Identity-Konto zuordnen. Dieses Konto bietet dann die Basis für eine einzelne GCP-Organisation, die Sie zur Verwaltung Ihrer GCP-Ressourcen verwenden können.

In einer Umgebung mit mehreren Domains besteht ein Unterschied zwischen den Informationen, die von einem Domaincontroller abgerufen werden können, und den Informationen, die von einem globalen Katalogserver abgefragt werden können. Domaincontroller stellen nur Daten aus ihrer lokalen Domain bereit. Globale Katalogserver hingegen bieten Zugriff auf Informationen aus allen Domains in der Gesamtstruktur. Entscheidend ist dabei, dass die Daten, die von globalen Katalogservern bereitgestellt werden, unvollständig sind und ihnen bestimmte LDAP-Attribute fehlen. Diese Einschränkung kann Auswirkungen darauf haben, wie Sie Cloud Directory Sync konfigurieren, um Gruppen zu synchronisieren.

Je nachdem, wie Sie Gruppen zuordnen möchten, erfordert der Verbund aus einer Gesamtstruktur mit mehreren Domains und der GCP eine oder mehrere Cloud Directory Sync-Instanzen. Zur Verarbeitung der Einmalanmeldung (SSO) ist jedoch nur eine einzige AD FS-Instanz oder -Flotte erforderlich.

Mehrere Gesamtstrukturen mit gesamtstrukturübergreifender Vertrauensstellung

Mehrere Gesamtstrukturen mit gesamtstrukturübergreifender Vertrauensstellung

In größeren Organisationen ist es nicht ungewöhnlich, mehr als eine Active Directory-Gesamtstruktur zu haben, oft infolge einer Fusion oder Übernahme. Sie können diese Gesamtstrukturen mithilfe einer bidirektionalen, gesamtstrukturübergreifenden Vertrauensstellung kombinieren, sodass die Freigabe von Ressourcen und der Nutzerzugriff nicht durch die Grenzen einer Gesamtstruktur eingeschränkt werden.

Wenn alle Gesamtstrukturen untereinander bidirektionale Vertrauensstellungen haben, können Sie die gesamte Umgebung einem einzigen Cloud Identity-Konto zuordnen. Dieses Konto bietet die Basis für eine einzelne GCP-Organisation, die Sie zur Verwaltung Ihrer GCP-Ressourcen verwenden können.

Globale Katalogserver bieten zwar Zugriff auf Daten aus mehreren Domains, sind jedoch auf eine einzige Gesamtstruktur beschränkt. In einer Umgebung mit mehreren Gesamtstrukturen müssen Sie also mehrere Domaincontroller oder globale Katalogserver abfragen, um beispielsweise eine vollständige Liste der Nutzerkonten zu erhalten. Aufgrund dieser Einschränkung erfordert der Verbund aus einer Umgebung mit mehreren Gesamtstrukturen und der GCP mindestens eine Cloud Directory Sync-Instanz pro Gesamtstruktur. Gesamtstrukturübergreifende Vertrauensstellungen ermöglichen die Nutzerauthentifizierung über Gesamtstrukturgrenzen hinweg, sodass zur Verarbeitung der Einmalanmeldung (SSO) nur eine einzige AD FS-Instanz oder -Flotte erforderlich ist.

Wenn Ihre Umgebung aus mehreren Gesamtstrukturen ohne gesamtstrukturübergreifende Vertrauensstellung besteht, aber alle Active Directory-Domains, die für den Verbund mit der GCP relevant sind, über externe Vertrauensstellungen verbunden sind, gelten die gleichen Voraussetzungen.

Mehrere Gesamtstrukturen ohne gesamtstrukturübergreifende Vertrauensstellung

Mehrere Gesamtstrukturen ohne gesamtstrukturübergreifende Vertrauensstellung

In der hier dargestellten Umgebung ist es nicht möglich, Ressourcen über die Gesamtstrukturgrenzen hinweg zu authentifizieren oder aufzurufen. Außerdem kann keine einzelne AD FS-Instanz oder -Flotte verwendet werden, um die SSO-Anfragen von Nutzern aus allen Gesamtstrukturen zu verarbeiten.

Daher ist es nicht möglich, mehrere Gesamtstrukturen ohne gesamtstrukturübergreifende Vertrauensstellungen einem einzelnen Cloud Identity-Konto zuzuordnen. Stattdessen muss jede Gesamtstruktur einem separaten Cloud Identity-Konto zugeordnet werden. Das erfordert mindestens eine Cloud Directory Sync-Instanz und einen AD FS-Server bzw. eine AD FS-Flotte pro Gesamtstruktur.

In der GCP wird für jedes Cloud Identity-Konto eine eigene Organisation erstellt. Normalerweise benötigen Sie keine separaten Organisationen. Sie können eine der Organisationen auswählen und mit den anderen Cloud Identity-Konten verknüpfen. Diese Organisation befindet sich dann in einem Verbund mit mehreren Active Directory-Gesamtstrukturen. Die übrigen Organisationen bleiben ungenutzt.

DNS-Domains zuordnen

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

DNS-Domains in Active Directory verwenden

In einer Active Directory-Gesamtstruktur werden DNS-Domains an mehreren Stellen verwendet:

  • Active Directory-DNS-Domains: Jede Active Directory-Domain entspricht einer DNS-Domain. Diese Domain kann global sein, wie corp.example.com, oder einen lokalen Domainnamen wie corp.local oder corp.internal haben.
  • Mail-Exchange-Domains (MX): E-Mail-Adressen verwenden eine DNS-Domain. Manchmal ist diese Domain mit der Active Directory-DNS-Domain identisch, doch meistens wird eine andere, oft kürzere Domain wie example.com verwendet. Idealerweise haben Nutzerkonten in Active Directory die E-Mail-Adresse, die mit dem optionalen mail-Attribut verknüpft ist.
  • UPN-Suffixdomains: Diese Domains werden für User Principal Names (UPNs) verwendet. Standardmäßig wird die Active Directory-DNS-Domain der Domain des Kontos verwendet, um einen UPN zu erstellen. Für den Nutzer john in der Domain corp.example.com lautet der Standard-UPN demnach john@corp.example.com. Sie können eine Gesamtstruktur jedoch so konfigurieren, dass zusätzliche DNS-Domains als UPN-Suffixe verwendet werden, die weder Active Directory-DNS-Domains noch MX-Domains entsprechen. UPNs sind optional und werden im Feld userPrincipalName des Nutzerkontos gespeichert.
  • Endpunktdomains: Öffentlichen Servern wie AD FS-Servern wird normalerweise ein DNS-Name zugewiesen, z. B. login.external.example.com. Die Domain, die für diese Zwecke verwendet wird, kann sich mit der MX-Domain, dem UPN-Suffix oder der Active Directory-DNS-Domain überschneiden. Sie können aber auch eine ganz andere Domain verwenden.

DNS-Domains in der GCP

Bei der Google Identity Platform, die in der GCP zur Authentifizierung genutzt wird, werden Nutzer über E-Mail-Adressen identifiziert. Dadurch wird gewährleistet, dass jeder Nutzer global eindeutig ist, aber vor allem ermöglicht es der GCP, Benachrichtigungen an die jeweiligen Adressen zu senden.

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

DNS-Domains in der GCP

Wenn Sie sich für ein G Suite- oder Cloud Identity-Konto registrieren, erstellen Sie im Grunde ein privates Verzeichnis, das die Google Identity Platform für die Authentifizierung verwenden kann. Genauso wie das Gmail-Verzeichnis mit der Domain gmail.com verknüpft ist, müssen G Suite- und Cloud Identity-Konten einer benutzerdefinierten Domain zugeordnet werden. Dabei werden drei verschiedene Arten von Domains verwendet:

  • Primäre Domain: Diese Domain identifiziert das Cloud Identity-Verzeichnis und wird auch als Name für die Organisation in der GCP 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 zusätzliche, sekundäre Domains zuordnen. Jedes Konto im Verzeichnis ist entweder mit der primären Domain oder einer sekundären Domain verknüpft. Zwei Konten, johndoe@example.com und johndoe@secondary.example.com, werden daher als separate Konten betrachtet, wenn example.com die primäre Domain und secondary.example.com die sekundäre Domain eines Verzeichnisses bilden.
  • Alias-Domain: Dies ist eine alternative Domain für die primäre Domain. Wenn alias.example.com als Alias-Domain eingerichtet ist, beziehen sich johndoe@example.com und johndoe@alias.example.com auf dasselbe Konto. Eine Alias-Domain kann nur einen alternativen Namen für die primäre Domain bereitstellen. Sie können keine Alias-Domains für sekundäre Domains hinzufügen.

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

  • Sie müssen gültige, globale DNS-Domainnamen sein. Lokale Domainnamen wie corp.local oder corp.internal, die häufig in Active Directory verwendet werden, sind nicht zulässig. Während der Einrichtung benötigen Sie möglicherweise 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 verwenden, z. B. subdomain.example.com, um auf verschiedene Verzeichnisse zu verweisen.
  • Primäre und sekundäre Domains sollten einen gültigen MX-Eintrag haben. So können Nachrichten an E-Mail-Adressen, die mit diesem Domainnamen gebildet werden, ordnungsgemäß zugestellt werden.

Damit die Verzeichnisse synchronisiert werden können, müssen zwischen den Active Directory-Domains und den von Cloud Identity verwendeten Domains gewisse Zuordnungen bestehen. Welche Zuordnung die richtige ist, hängt davon ab, wie Sie Active Directory verwenden. Dazu ist es erforderlich, genauer zu untersuchen, wie Nutzerkonten in einer Active Directory-Gesamtstruktur identifiziert werden und wie sie Cloud Identity zugeordnet werden können.

Nutzerkonten zuordnen

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

Nutzerkonten in Active Directory identifizieren

Intern verwendet Active Directory zwei Kennzeichnungen, um Nutzerkonten eindeutig zu identifizieren:

  • objectGUID: Diese global eindeutige ID wird bei der Erstellung eines Nutzers erzeugt und ändert sich nie.
  • objectSID: Die Sicherheits-ID (SID) wird für alle Zugriffsprüfungen verwendet. Innerhalb einer Domain ist diese ID eindeutig und stabil. Allerdings wird einem Konto möglicherweise eine neue SID zugewiesen, wenn es in eine andere Domain in der Gesamtstruktur verschoben wird.

Keine dieser IDs ist für die Nutzer aussagekräftig. Daher bietet Active Directory zwei nutzerfreundliche Methoden zum Identifizieren von Nutzerkonten:

  • UPN (userPrincipalName): Die bevorzugte Methode zum Identifizieren eines Nutzerkontos ist die Verwendung eines UPNs. UPNs richten sich nach dem RFC 822-Format für E-Mail-Adressen und werden durch die Kombination eines Nutzernamens mit einer UPN-Suffixdomain erstellt. Beispiel: johndoe@corp.example.com. UPNs sind die bevorzugte Methode, um Nutzerkonten zu identifizieren. Trotzdem sind sie optional. Bei einigen Nutzerkonten in Ihrer Active Directory-Gesamtstruktur ist deshalb möglicherweise kein UPN vorhanden.

    Es gilt als Best Practice, gültige E-Mail-Adressen als UPNs zu verwenden. Dies muss in Active Directory jedoch nicht zwingend eingehalten werden.

  • Anmeldename für Versionen vor Windows 2000 (sAMAccountName): Dieser Name kombiniert den NetBIOS-Domainnamen und den Nutzernamen unter Verwendung des Formats domain\user, wie in corp\johndoe. Obwohl diese Namen als veraltet gelten, werden sie weiterhin verwendet und sind die einzige obligatorische Kennzeichnung eines Nutzerkontos.

Active Directory verwendet zur Identifizierung eines Nutzers nicht seine E-Mail-Adresse (mail). Daher ist dieses Feld nicht obligatorisch und muss in einer Gesamtstruktur auch nicht eindeutig sein.

Alle diese Kennzeichnungen können jederzeit geändert werden.

Kontoidentitäten zuordnen

Für die Zuordnung zwischen Active Directory- und Cloud Identity-Konten sind für jedes Nutzerkonto zwei Informationen erforderlich:

  • Eine stabile, eindeutige ID, die Sie während der Synchronisierung verwenden können, um zu ermitteln, welches Active Directory-Konto welchem Cloud Identity-Konto entspricht. Auf der AD-Seite ist die objectGUID für diesen Zweck perfekt geeignet.
  • Eine E-Mail-Adresse, deren Domainteil einer primären, sekundären oder Alias-Domain von Cloud Identity entspricht. Da diese E-Mail-Adresse in der gesamten GCP verwendet wird, sollte Sie möglichst aussagekräftig sein. Eine aus der objectGUID abgeleitete Adresse ist ebenso unzweckmäßig wie andere automatisch generierte E-Mail-Adressen.

Ein Active Directory-Nutzerkonto hat zwei Felder, die sich für die Bereitstellung einer Cloud Identity-E-Mail-Adresse eignen: userPrincipalName und mail.

Nach User Principal Name (UPN) zuordnen

Wenn Sie das Feld userPrincipalName verwenden, müssen zwei Kriterien für alle zu synchronisierenden Konten erfüllt sein:

  • UPNs müssen gültige E-Mail-Adressen sein. Alle Domains, die als UPN-Suffixdomains verwendet werden, müssen auch MX-Domains sein. Außerdem müssen sie so eingerichtet sein, dass E-Mails, die an den UPN eines Nutzers gesendet werden, in seinem E-Mail-Posteingang eingehen.
  • Die UPN-Zuweisung muss abgeschlossen sein. Allen zu synchronisierenden Nutzerkonten muss ein UPN zugewiesen sein. Mit dem folgenden PowerShell-Befehl können Sie nach Konten suchen, die keinen UPN haben:

    Get-ADUser -LDAPFilter "(!userPrincipalName=*)"

Wenn diese beiden Kriterien erfüllt sind, können Sie UPNs bedenkenlos Cloud Identity-E-Mail-Adressen zuordnen. Sie können eine der UPN-Suffixdomains als primäre Domain in Cloud Identity verwenden und alle anderen UPN-Suffixdomains als sekundäre Domains hinzufügen.

Ist eins der Kriterien nicht erfüllt, können Sie UPNs trotzdem Cloud Identity-E-Mail-Adressen zuordnen. Allerdings gelten dann folgende Einschränkungen:

  • Wenn UPNs keine gültigen E-Mail-Adressen sind, erhalten Nutzer möglicherweise keine Benachrichtigungs-E-Mails von der GCP. Dadurch können den Nutzern wichtige Informationen entgehen.
  • Konten ohne UPNs werden während der Synchronisierung ignoriert.
  • Sie können die Synchronisierung so konfigurieren, dass die UPN-Suffixdomain durch eine andere Domain ersetzt wird. Wenn Sie mehrere UPN-Suffixdomains in einer Gesamtstruktur verwenden, können dabei jedoch Duplikate entstehen, da alle UPN-Suffixdomains durch eine einzige Domain ersetzt werden. Wenn Duplikate vorliegen, kann nur ein einziges Konto synchronisiert werden.

Die Zuordnung von Nutzern per UPN bieten den großen Vorteil, dass UPNs in einer Gesamtstruktur garantiert eindeutig sind und eine ausgewählte Gruppe von Domains verwenden. Dadurch können potenzielle Probleme bei der Synchronisierung vermieden werden.

Nach E-Mail-Adresse zuordnen

Wenn Sie das Feld mail verwenden, muss das folgende Kriterium für alle zu synchronisierenden Konten erfüllt sein:

  • Die E-Mail-Zuweisung muss abgeschlossen sein. Bei allen zu synchronisierenden Nutzerkonten muss das Feld mail ausgefüllt sein. Mit dem folgenden PowerShell-Befehl können Sie nach Konten suchen, bei denen dieses Feld nicht ausgefüllt ist:

    Get-ADUser -LDAPFilter "(!mail=*)"
  • Für alle E-Mail-Adressen muss eine ausgewählte Gruppe von Domains verwendet werden, die Ihnen gehören. Wenn einige Ihrer Konten E-Mail-Adressen mit Domains von Partnerunternehmen oder privaten E-Mail-Anbietern enthalten, können diese E-Mail-Adressen nicht verwendet werden.

  • Alle E-Mail-Adressen müssen in der Gesamtstruktur eindeutig sein. Da die Eindeutigkeit in Active Directory nicht erzwungen wird, müssen Sie möglicherweise benutzerdefinierte Prüfungen oder Richtlinien implementieren.

Wenn alle relevanten Konten diese Kriterien erfüllen, können Sie alle Domains ermitteln, die von diesen E-Mail-Adressen verwendet werden, und als primäre und sekundäre Domains in Cloud Identity nutzen.

Ist eins der Kriterien nicht erfüllt, können Sie UPNs trotzdem Cloud Identity-E-Mail-Adressen zuordnen. Allerdings gelten dann folgende Einschränkungen:

  • Konten ohne E-Mail-Adressen werden während der Synchronisierung ebenso ignoriert wie Konten mit E-Mail-Adressen, die Domains verwenden, die nicht dem Cloud Identity-Verzeichnis zugeordnet sind.
  • Wenn zwei Konten dieselbe E-Mail-Adresse verwenden, wird nur ein Konto synchronisiert.
  • Sie können die Synchronisierung so konfigurieren, dass die Domain der E-Mail-Adressen durch eine andere Domain ersetzt wird. Wenn dabei Duplikate entstehen, wird nur eins der beiden Konten synchronisiert.

Gruppen zuordnen

Der vierte Faktor, den Sie beim Verbinden von Active Directory mit der GCP berücksichtigen sollten, ist die Synchronisierung und die Zuordnung von Gruppen zwischen Active Directory und der GCP.

In der GCP 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 Gruppen fest, die allgemeine Rollen in Ihrer Organisation abbilden, und ordnen diese Gruppen dann einer Reihe von Cloud IAM-Rollen zu. Über die Gruppen können Sie den Nutzerzugriff auf unterschiedliche Ressourcen steuern.

In Active Directory werden zwei Arten von Gruppen unterschieden: Verteilergruppen und Sicherheitsgruppen. Verteilergruppen werden verwendet, um E-Mail-Listen zu verwalten. Die Synchronisierung von Verteilergruppen ist wichtig, wenn Sie von Microsoft Exchange zu G Suite migrieren. Cloud Directory Sync kann daher normale und dynamische Verteilergruppen verarbeiten. Bei der Identitäts- und Zugriffsverwaltung für die GCP spielen Verteilergruppen jedoch keine Rolle. Deshalb konzentriert sich dieser Artikel ausschließlich auf Sicherheitsgruppen.

Die Zuordnung von Sicherheitsgruppen zwischen Active Directory und der GCP ist optional. Wenn die Nutzerkonten verbunden sind, können Sie Gruppen direkt in Cloud Identity erstellen und verwalten. Active Directory bleibt das zentrale System für die Identitätsverwaltung, nicht jedoch für die Zugriffsverwaltung. Wenn Sie Active Directory als zentrales System für die Identitätsverwaltung und die Zugriffsverwaltung verwenden möchten, sollten Sie Sicherheitsgruppen aus Active Directory synchronisieren, statt sie in Cloud Identity zu verwalten. Dadurch erhalten Sie die Möglichkeit, Cloud IAM so einzurichten, dass Sie über Gruppenmitgliedschaften in Active Directory steuern können, welche Nutzer Zugriff auf bestimmte Ressourcen in der GCP haben.

Sicherheitsgruppen in Active Directory

Sicherheitsgruppen spielen eine grundlegende Rolle bei der Windows-Sicherheitsverwaltung und der Active Directory-Zugriffsverwaltung. Diese Rolle stützt sich auf drei verschiedene Arten von Active Directory-Gruppen: lokale Domaingruppen, globale Gruppen und Universelle Gruppen.

Sicherheitsgruppen in AD

Lokale Domaingruppen
Diese Gruppen sind nur im Bereich einer einzelnen Domain relevant und können nicht in anderen Domains referenziert werden. Da die Liste ihrer Mitglieder nicht in der Gesamtstruktur repliziert werden muss, sind lokale Domaingruppen in Bezug auf die möglichen Mitglieder am flexibelsten.
Globale Gruppen
Diese Gruppen werden in anderen Domains angezeigt und können dort referenziert werden. Ihre Mitgliederliste wird jedoch nicht repliziert. Aufgrund dieser Einschränkung können diese Gruppen nicht alle Arten von Mitgliedern enthalten. Sie können nur Nutzerkonten und andere globale Gruppen derselben Domain enthalten.
Universelle Gruppen
Diese Gruppen werden zusammen mit ihren Mitgliederlisten in der Gesamtstruktur repliziert. Sie können daher in anderen Domains referenziert werden und nicht nur Nutzerkonten und andere universelle Gruppen, sondern auch globale Gruppen aus allen Domains enthalten.

Wenn Ihre Active Directory-Gesamtstruktur nur eine einzige Domain enthält, können Sie alle drei Arten von Sicherheitsgruppen mit Cloud Directory Sync synchronisieren. Verwendet Ihre Active Directory-Gesamtstruktur mehrere Domains, wird durch den Typ einer Gruppe bestimmt, ob und wie sie mit Cloud Identity synchronisiert werden kann.

Da lokale Domaingruppen und globale Gruppen in einer Gesamtstruktur nicht vollständig repliziert werden, enthalten globale Katalogserver nur unvollständige Informationen zu diesen Gruppen. Diese Einschränkung ist zwar beabsichtigt und beschleunigt die Verzeichnisreplikation, stellt jedoch ein Hindernis dar, wenn Sie diese Gruppen mit Cloud Identity synchronisieren möchten. Das gilt insbesondere dann, wenn Sie Cloud Directory Sync so konfigurieren, dass ein globaler Katalogserver als Quelle verwendet wird. Das Tool kann in diesem Fall Gruppen aus allen Domains in der Gesamtstruktur finden. Nur Gruppen, die sich in derselben Domain wie der globale Katalogserver befinden, enthalten jedoch eine Mitgliederliste und sind für die Replikation geeignet. Wenn Sie lokale Domaingruppen oder globale Gruppen in einer Gesamtstruktur mit mehreren Domains synchronisieren wollen, müssen Sie für jede Domain eine separate Cloud Directory Sync-Instanz ausführen.

Für universelle Gruppen gilt diese Einschränkung nicht, da sie in der Gesamtstruktur vollständig repliziert werden. Zur Synchronisierung universeller Gruppen aus mehreren Domains ist demnach nur eine einzige Cloud Directory Sync-Instanz erforderlich.

Bevor Sie zu dem Schluss kommen, dass Sie mehrere Cloud Directory Sync-Instanzen benötigen, um mehrere Active Directory-Domains mit Cloud Identity zu synchronisieren, sollten Sie bedenken, dass möglicherweise nicht alle Gruppen synchronisiert werden müssen. Deshalb lohnt es sich zu untersuchen, wie verschiedene Arten von Sicherheitsgruppen normalerweise in Ihrer Active Directory-Gesamtstruktur verwendet werden.

Sicherheitsgruppen in Active Directory

Ressourcengruppen

Das Zugriffsmodell von Windows basiert auf Access Control Lists (ACLs). Jede Ressource, z. B. eine Datei oder ein LDAP-Objekt, hat eine verknüpfte ACL, über die der Nutzerzugriff gesteuert wird. Da Ressourcen und ACLs sehr genau abgestimmt sind, liegen sie in großer Zahl vor. Zur Vereinfachung der ACL-Verwaltung können Ressourcengruppen erstellt werden, um Ressourcen zu bündeln, die häufig zusammen aufgerufen und verwendet werden. Eine Ressourcengruppe muss allen betroffenen ACLs nur einmal hinzugefügt werden. Den weiteren Zugriff verwalten Sie, indem Sie die Ressourcen in der Gruppe ändern statt die ACLs.

Die auf diese Weise gruppierten Ressourcen befinden sich normalerweise in einer einzelnen Domain. Folglich wird eine Ressourcengruppe in der Regel nur in einer einzelnen Domain referenziert, entweder in ACLs oder von anderen Ressourcengruppen. Da die meisten Ressourcengruppen lokal sind, werden sie normalerweise mithilfe von lokalen Domaingruppen in Active Directory implementiert.

Rollen- und Organisationsgruppen

Ressourcengruppen vereinfachen die Zugriffsverwaltung. In einer großen Umgebung kann es jedoch passieren, dass Sie einen neuen Nutzer einer großen Anzahl von Ressourcengruppen hinzufügen müssen. Daher werden Ressourcengruppen meistens um Rollengruppen oder Organisationsgruppen ergänzt.

Mit Rollengruppen werden die Berechtigungen zusammengefasst, die eine bestimmte Rolle in der Organisation erfordert. Eine Rollengruppe mit der Bezeichnung "Betrachter technische Dokumentation" kann den Mitgliedern z. B. Lesezugriff auf die gesamte technische Dokumentation gewähren. In der Praxis würden Sie dazu eine Rollengruppe erstellen und zu einem Mitglied aller Ressourcengruppen machen, die zur Steuerung des Zugriffs auf verschiedene Dokumentationstypen verwendet werden.

Auf ähnliche Weise werden in Organisationsgruppen die Berechtigungen zusammengefasst, die von Abteilungen innerhalb einer Organisation benötigt werden. Eine Organisationsgruppe mit dem Namen "Technik" kann z. B. Zugriff auf alle Ressourcen gewähren, die Mitglieder der Technikabteilung häufig benötigen.

Im Grunde gibt es keinen Unterschied zwischen Rollengruppen und Ressourcengruppen. Sie werden in der Regel sogar zusammen eingesetzt. Im Gegensatz zu Ressourcengruppen können Rollen- und Organisationsgruppen jedoch über die Grenzen einer Domain hinaus relevant sein. Damit diese Gruppen von Ressourcengruppen in anderen Domains referenziert werden können, werden Rollen- und Organisationsgruppen normalerweise mithilfe von globalen Gruppen implementiert, die sich auf Mitglieder einer einzelnen Domain beschränken, und manchmal um universelle Gruppen ergänzt, die Mitglieder aus verschiedenen Domains enthalten können.

Im folgenden Diagramm wird ein Verschachtelungsmuster gezeigt, das häufig in Active Directory-Umgebungen mit mehreren Domains verwendet wird.

Verschachtelungsmuster in AD-Umgebungen mit mehreren Domains

Gruppen in Cloud Identity

In Cloud Identity gibt es nur einen einzigen Gruppentyp. Er verhält sich ähnlich wie universelle Gruppen in Active Directory. Gruppen sind nicht auf den Bereich des Cloud Identity-Kontos beschränkt, in dem sie definiert wurden. Sie können Nutzerkonten aus verschiedenen Cloud Identity-Konten enthalten. Diese Gruppen können in anderen Cloud Identity-Konten referenziert und verschachtelt sowie in jeder GCP-Organisation verwendet werden.

Im Gegensatz zu Active Directory-Gruppen erhalten Mitglieder einer Cloud Identity-Gruppe nicht implizit die Berechtigung, andere Mitglieder derselben Gruppe aufzulisten. Stattdessen ist für das Abfragen der Gruppenmitgliedschaft in der Regel eine explizite Autorisierung erforderlich.

Gruppen in der GCP verwenden

In der GCP wird statt einem ACL-basierten Zugriffsmodell ein rollenbasiertes Modell verwendet. Rollen gelten für alle Ressourcen eines bestimmten Typs in einem bestimmten Bereich. Die Rolle "Kubernetes Engine-Entwickler" hat z. B. in allen Clustern eines Projekts vollen Zugriff auf Kubernetes API-Objekte. Aufgrund der Art der Rollen besteht ein geringer Verwaltungsbedarf für die Ressourcengruppen in der GCP. Die Ressourcengruppen müssen auch nur selten mit der GCP synchronisiert werden.

Rollen- und Organisationsgruppen sind in der GCP genauso relevant wie in Active Directory, da sie die Zugriffsverwaltung bei einer großen Anzahl von Nutzern vereinfachen. Durch das Synchronisieren von Rollen- und Organisationsgruppen bleibt Active Directory die zentrale Anlaufstelle für die Zugriffsverwaltung.

Rollen- und Organisationsgruppen synchronisieren

Wenn Sie Ressourcengruppen konsequent als lokale Domaingruppen und Rollen- und Organisationsgruppen als globale oder universelle Gruppen implementieren, können Sie mithilfe des Gruppentyps festlegen, dass nur Rollen- und Organisationsgruppen synchronisiert werden.

Jetzt lautet die Frage nicht mehr, ob eine einzelne Instanz von Cloud Directory Sync pro Gesamtstruktur mit mehreren Domains ausreicht oder ob Sie mehrere Instanzen von Cloud Directory Sync benötigen, sondern ob Sie globale Gruppen verwenden sollten. Wenn Sie alle Rollen- und Organisationsgruppen mithilfe von universellen Gruppen implementieren, reicht eine einzige Instanz von Cloud Directory Sync aus. Andernfalls benötigen Sie eine Instanz von Cloud Directory Sync für jede Domain.

Gruppenidentitäten zuordnen

Für die Zuordnung von Active Directory-Sicherheitsgruppen zu Cloud Identity-Gruppen ist eine gemeinsame Kennzeichnung erforderlich. In Cloud Identity muss diese Kennzeichnung eine E-Mail-Adresse sein, deren Domainteil einer primären, sekundären oder Alias-Domain von Cloud Identity entspricht. Da diese E-Mail-Adresse in der gesamten GCP verwendet wird, muss sie für Menschen lesbar sein. Der E-Mail-Adresse muss kein Posteingang zugeordnet sein.

In Active Directory werden Gruppen entweder anhand ihres allgemeinen Namens (cn) oder anhand eines Anmeldenamens für Prä-Windows 2000 (sAMAccountName) identifiziert. Ähnlich wie Nutzerkonten können Gruppen auch eine E-Mail-Adresse haben (mail). E-Mail-Adressen sind für Gruppen jedoch nur ein optionales Attribut und ihre Eindeutigkeit wird von Active Directory nicht überprüft.

Sie haben zwei Möglichkeiten, um Gruppenidentitäten zwischen Active Directory und Cloud Identity zuzuordnen.

Nach allgemeinem Namen zuordnen

Die Zuordnung nach allgemeinem Namen (cn) hat den Vorteil, dass dieser garantiert verfügbar und zumindest innerhalb einer Organisationseinheit eindeutig ist. Der allgemeine Name ist jedoch keine E-Mail-Adresse. Deshalb muss das Suffix @[DOMAIN] angehängt werden, um den Namen als E-Mail-Adresse zu verwenden.

Sie können Cloud Directory Sync so konfigurieren, dass automatisch ein Suffix an den Gruppennamen angehängt wird. Active Directory sorgt dafür, dass zwischen Gruppennamen und Nutzerkontonamen kein Konflikt auftritt. Deshalb sind Konflikte durch eine auf diese Weise abgeleitete E-Mail-Adresse unwahrscheinlich.

Wenn Ihre Active Directory-Gesamtstruktur mehrere Domains enthält, gelten folgende Einschränkungen:

  • Wenn zwei Gruppen in verschiedenen Domains denselben allgemeinen Namen haben, kommt es zu einem Konflikt mit der abgeleiteten E-Mail-Adresse. Dadurch wird eine Gruppe während der Synchronisierung ignoriert.
  • Sie können nur Gruppen aus Domains einer einzelnen Gesamtstruktur synchronisieren. Wenn Sie Gruppen aus mehreren Gesamtstrukturen mithilfe separater Cloud Directory Sync-Instanzen synchronisieren, spiegeln die E-Mail-Adressen, die vom allgemeinen Namen abgeleitet werden, nicht ihre Gesamtstruktur wider. Aufgrund dieser Mehrdeutigkeit löscht eine Cloud Directory Sync-Instanz Gruppen, die zuvor von einer anderen Cloud Directory Sync-Instanz aus einer anderen Gesamtstruktur erstellt wurden.
  • Sie können Gruppen nicht nach allgemeinen Namen zuordnen, wenn Sie für die Zuordnung von Nutzerkonten die Domainsubstitution verwenden.

Nach E-Mail-Adresse zuordnen

Wenn Sie Gruppenidentitäten anhand der E-Mail-Adresse (mail) zuordnen, müssen die gleichen Kriterien erfüllt werden wie beim Zuordnen der Kontoidentitäten anhand der E-Mail-Adresse:

  • Die E-Mail-Zuweisung muss abgeschlossen sein. Verteilergruppen verfügen zwar häufig über eine E-Mail-Adresse, bei Sicherheitsgruppen fehlt dieses Attribut jedoch häufig. Damit die E-Mail-Adresse für das Zuordnen von Identitäten verwendet werden kann, muss bei synchronisierten Sicherheitsgruppen das Feld mail ausgefüllt sein. Mit dem folgenden PowerShell-Befehl können Sie nach Konten suchen, bei denen dieses Feld nicht ausgefüllt ist:

    Get-ADGroup -LDAPFilter "(!mail=*)"
  • Für alle E-Mail-Adressen muss eine ausgewählte Gruppe von Domains verwendet werden, die Ihnen gehören. Wenn einige Ihrer Konten E-Mail-Adressen mit Domains von Partnerunternehmen oder privaten E-Mail-Anbietern enthalten, können Sie diese Adressen nicht verwenden.

  • Alle E-Mail-Konten müssen in der Gesamtstruktur eindeutig sein. Da die Eindeutigkeit in Active Directory nicht erzwungen wird, müssen Sie möglicherweise benutzerdefinierte Prüfungen oder Richtlinien implementieren.

Wenn alle relevanten Gruppen diese Kriterien erfüllen, können Sie alle Domains ermitteln, die von diesen E-Mail-Adressen verwendet werden, und dafür sorgen, dass diese Domains in der Liste der in Cloud Identity registrierten DNS-Domains enthalten sind.

Ist eins der Kriterien nicht erfüllt, können Sie UPNs trotzdem Cloud Identity-E-Mail-Adressen zuordnen. Allerdings gelten dann folgende Einschränkungen:

  • Gruppen ohne E-Mail-Adressen werden während der Synchronisierung ebenso ignoriert wie E-Mail-Adressen mit Domains, die nicht dem Cloud Identity-Verzeichnis zugeordnet sind.
  • Wenn zwei Gruppen dieselbe E-Mail-Adresse verwenden, wird nur eine davon synchronisiert.

Die Zuordnung von Gruppen nach E-Mail-Adressen wird nicht unterstützt, wenn die Active Directory-Gesamtstruktur mehr als eine Domain enthält und Nutzerkonten per Domainsubstitution zugeordnet werden.

Organisationseinheiten zuordnen

In den meisten Active Directory-Domains werden Organisationseinheiten verwendet, um Ressourcen zu gruppieren und hierarchisch zu organisieren, den Zugriff zu steuern und Richtlinien durchzusetzen.

In der GCP haben Ordner und Projekte einen ähnlichen Zweck. Allerdings werden in einer GCP-Organisation andere Ressourcenarten verwaltet als in Active Directory. Daher unterscheidet sich eine für ein Unternehmen geeignete GCP-Ordnerhierarchie erheblich von der Struktur der Organisationseinheiten in Active Directory. Die automatische Zuordnung von Organisationseinheiten zu Ordnern und Projekten ist deshalb selten praktikabel und wird von Cloud Directory Sync nicht unterstützt.

Unabhängig von den Ordnern unterstützt Cloud Identity Organisationseinheiten. Organisationseinheiten werden ähnlich wie in Active Directory zum Gruppieren und Organisieren von Nutzerkonten erstellt. Anders als bei Active Directory gelten sie jedoch nur für Nutzerkonten, nicht für Gruppen.

Cloud Directory Sync bietet die Option, Organisationseinheiten von Active Directory mit Organisationseinheiten von Cloud Identity zu synchronisieren. In Umgebungen, in denen Cloud Identity lediglich zur Erweiterung der Active Directory-Identitätsverwaltung in der GCP verwendet wird, ist die Zuordnung von Organisationseinheiten normalerweise nicht erforderlich.

Die richtige Zuordnung

Wie bereits am Anfang dieses Artikels erwähnt, gibt es keine allgemeingültige optimale Methode, um die Strukturen von Active Directory und der GCP zuzuordnen. In den folgenden Entscheidungsdiagrammen werden die Kriterien zusammengefasst, die in den vorherigen Abschnitten erörtert wurden. Dies soll Ihnen als Hilfestellung dienen, die optimale Zuordnung für Ihr jeweiliges Szenario auszuwählen.

Ermitteln Sie zuerst anhand des folgenden Diagramms, wie viele Cloud Identity-Konten, Cloud Directory Sync-Instanzen und AD FS-Instanzen oder -Flotten Sie benötigen.

Entscheidungsdiagramm zur Bestimmung der Anzahl benötigter Flotten oder Instanzen

In der zweiten Tabelle finden Sie Informationen zur Identifizierung der Domains, die in Ihrem Cloud Identity-Konto konfiguriert werden sollen.

Entscheidungsdiagramm zur Identifizierung der in Cloud Identity zu konfigurierenden Domains

Weitere Informationen