In diesem Dokument wird beschrieben, wie Sie Cloud Identity oder Google Workspace so konfigurieren können, dass sie Active Directory als IdP und autoritative Quelle verwenden.
Das Dokument vergleicht die logische Struktur von Active Directory mit der von Cloud Identity und Google Workspace verwendeten Struktur und beschreibt, wie Sie Active Directory-Gesamtstrukturen, -Domains, -Nutzer und -Gruppen zuordnen können. Das Dokument enthält auch ein Flussdiagramm, mit dem Sie die beste Zuordnung für Ihr Szenario ermitteln können.
In diesem Dokument wird davon ausgegangen, dass Sie mit Active Directory vertraut sind.
Föderation implementieren
Google Cloud verwendet zur Authentifizierung und für die Zugriffsverwaltung Google-Identitäten. Wenn alle Mitarbeiter bereits ein Konto in Active Directory haben, kann die manuelle Verwaltung der Google-Identitäten für jeden Mitarbeiter unnötigen Verwaltungsaufwand verursachen. Wenn Sie aber Nutzeridentitäten in Google Cloud und im Identitätsverwaltungssystem miteinander verbinden, können Sie die Verwaltung von Google-Identitäten automatisieren und ihren Lebenszyklus mit vorhandenen Nutzern in Active Directory verknüpfen.
Das Einrichten einer Verbindung zwischen Active Directory und Cloud Identity oder Google Workspace besteht aus zwei Teilen:
Nutzer bereitstellen: Relevante Nutzer und Gruppen werden regelmäßig von Active Directory auf Cloud Identity oder Google Workspace synchronisiert. Dadurch wird sichergestellt, dass beim Erstellen eines neuen Nutzers in Active Directory auf ihn in Google Cloud verwiesen werden kann, noch bevor sich der zugeordnete Nutzer zum ersten Mal angemeldet hat. Durch diesen Prozess sorgen Sie auch dafür, dass die Information über gelöschte Nutzer weitergegeben wird.
Die Bereitstellung funktioniert nur in eine Richtung. Das bedeutet, dass Änderungen in Active Directory in Google Cloud repliziert werden, jedoch nicht umgekehrt. Außerdem umfasst die Bereitstellung keine Passwörter. In einer Verbundeinrichtung bleibt Active Directory das einzige System, das diese Anmeldeinformationen verwaltet.
Einmalanmeldung (SSO): Immer wenn sich ein Nutzer authentifizieren muss, delegiert Google Cloud 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 der entsprechende Nutzer jedoch zuvor bereitgestellt worden sein.
Zum Implementieren eines Verbunds können Sie die folgenden Tools verwenden:
- Google Cloud Directory Sync (GCDS) ist ein von Google bereitgestelltes kostenloses Tool, mit dem der Synchronisierungsprozess implementiert wird. GCDS kommuniziert per Secure Socket Layer (SSL) mit Google Cloud und wird normalerweise in der vorhandenen Computing-Umgebung 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 Cloud öffentlich verfügbar sind und SAML ein offener Standard ist, stehen viele Tools zur Verfügung, um einen Verbund zu implementieren. Der Schwerpunkt dieses Dokuments liegt auf der Verwendung von GCDS 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-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 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. Organisationen, Ordner und Projekte haben daher einen ähnlichen Zweck wie Active Directory-Domains.
Active Directory behandelt Nutzer als Ressourcen, sodass die Nutzerverwaltung und -authentifizierung an Domains gebunden ist. In Google Cloud hingegen werden Nutzer, abgesehen von Dienstkonten, nicht in einer Organisation verwaltet. Google Cloud verwendet stattdessen Cloud Identity oder Google Workspace, um Nutzer zu verwalten.
Ein Cloud Identity- oder Google Workspace-Konto dient als privates Verzeichnis für Nutzer und Gruppen. Als Administrator des Kontos können Sie den Lebenszyklus und die Konfiguration von Nutzern und Gruppen steuern und festlegen, wie die Authentifizierung durchgeführt werden soll.
Wenn Sie ein Cloud Identity- oder Google Workspace-Konto erstellen, wird automatisch eine Google Cloud-Organisation für Sie angelegt. Das Cloud Identity- oder Google Workspace-Konto und die damit verknüpfte Google Cloud-Organisation haben denselben Namen und sind aneinandergebunden. Eine Google Cloud-Organisation kann aber auf Nutzer und Gruppen aus anderen Cloud Identity- oder Google Workspace-Konten verweisen.
Active Directory und Google Cloud einbinden
Trotz gewisser Ähnlichkeiten zwischen der logischen Struktur von Active Directory 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 von mehreren Faktoren ab:
- Zuordnung von Domains und Gesamtstrukturen zu Cloud Identity- oder Google Workspace-Konten
- Zuordnung von DNS-Domains
- Zuordnung von Nutzern
- 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 Google Cloud verbinden möchten, sollten Sie zuerst die Topologie Ihrer Active Directory-Infrastruktur prüfen.
Eine Gesamtstruktur, eine Domain
Wenn eine Gesamtstruktur nur eine Domain enthält, können Sie die vollständige Active Directory-Gesamtstruktur einem einzelnen Cloud Identity oder Google Workspace-Konto zuordnen. Dieses Konto bietet dann die Basis für eine einzelne Google Cloud-Organisation, die Sie zur Verwaltung Ihrer Google Cloud-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 GCDS ausführen, um Nutzerkonten und -gruppen mit der Google Cloud zu synchronisieren, und eine einzelne AD FS-Instanz oder -Flotte zur Verarbeitung der Einmalanmeldung (SSO) einsetzen.
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 vollständige Gesamtstruktur einem einzigen Cloud Identity- oder Google Workspace-Konto zuordnen. Dieses Konto bietet dann die Basis für eine einzelne Google Cloud-Organisation, die Sie zur Verwaltung Ihrer Google Cloud-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 GCDS konfigurieren, um Gruppen zu synchronisieren.
Je nachdem, wie Sie Gruppen zuordnen möchten, erfordert der Verbund aus einer Gesamtstruktur mit mehreren Domains und Google Cloud eine oder mehrere GCDS-Instanzen. Zur Verarbeitung der Einmalanmeldung (SSO) ist jedoch nur eine einzige AD FS-Instanz oder -Flotte erforderlich.
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- oder Google Workspace-Konto zuordnen. Dieses Konto bietet die Basis für eine einzelne Google Cloud-Organisation, die Sie zur Verwaltung Ihrer Google Cloud-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 Google Cloud mindestens eine GCDS-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 Google Cloud relevant sind, über externe Vertrauensstellungen verbunden sind, gelten die gleichen Voraussetzungen.
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- oder Google Workspace-Konto zuzuordnen. Stattdessen muss jede Gesamtstruktur einem separaten Cloud Identity- oder Google Workspace-Konto zugeordnet werden. Das erfordert mindestens eine GCDS-Instanz und einen AD FS-Server bzw. eine AD FS-Flotte pro Gesamtstruktur.
In Google Cloud wird für jedes Cloud Identity- oder Google Workspace-Konto eine separate Organisation erstellt. Normalerweise benötigen Sie keine separaten Organisationen. Sie können eine der Organisationen auswählen und mit den anderen Cloud Identity- oder Google Workspace-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 und Google Workspace eine entscheidende Rolle. Der zweite Faktor, den Sie beim Verbinden von Active Directory mit Google Cloud berücksichtigen sollten, ist die gemeinsame Nutzung oder Zuordnung von DNS-Domains zwischen Active Directory und Google Cloud.
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 wiecorp.localodercorp.internalhaben. - 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.comverwendet. Idealerweise haben Nutzer in Active Directory die E-Mail-Adresse, die mit dem optionalenmail-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 Nutzers verwendet, um einen UPN zu erstellen. Für den Nutzer john in der Domain
corp.example.comlautet der Standard-UPN demnachjohn@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 FelduserPrincipalNamedes Nutzers 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 Google Cloud
Google Log-in, das Google Cloud zur Authentifizierung nutzt, identifiziert Nutzer mithilfe von E-Mail-Adressen. 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.
Google Log-in bestimmt das Verzeichnis oder den Identitätsanbieter für die Authentifizierung eines Nutzers auf Basis des Domainteils der E-Mail-Adressen, der auf @ folgt. Für eine E-Mail-Adresse, die die Domain gmail.com verwendet, zieht Google Log-in beispielsweise das Verzeichnis der Gmail-Nutzer zur Authentifizierung heran.
Wenn Sie sich für ein Google Workspace- oder Cloud Identity-Konto registrieren, erstellen Sie ein privates Verzeichnis, das Log-in für die Authentifizierung verwendet. Ebenso wie das Gmail-Verzeichnis mit der Domain gmail.com verknüpft ist, müssen Google Workspace- und Cloud Identity-Konten mit einer benutzerdefinierten Domain verknüpft werden.
Dabei werden drei verschiedene Arten von Domains verwendet:
- Primäre Domain: Diese Domain identifiziert das Cloud Identity- oder Google Workspace-Konto und wird als Name für die Organisation in Google Cloud verwendet. Bei der Registrierung für Cloud Identity oder Google Workspace haben Sie bereits einen Super Admin-Nutzer erstellt.
- Sekundäre Domain: Neben der primären Domain können Sie einem Cloud Identity- oder Google Workspace-Konto weitere sekundäre Domains zuordnen. Jeder Nutzer im Verzeichnis ist entweder der primären Domain oder einer der sekundären Domains zugeordnet. Die zwei Nutzer
johndoe@example.comundjohndoe@secondary.example.comwerden als separate Nutzer betrachtet, wennexample.comdie primäre Domain undsecondary.example.comeine sekundäre Domain ist. - Aliasdomain: Eine Aliasdomain ist ein alternativer Name für eine andere Domain.
Das heißt, dass
johndoe@example.comundjohndoe@alias.example.comsich auf denselben Nutzer beziehen, wennalias.example.comals Aliasdomain fürexample.comeingerichtet ist.
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.comkann nur auf ein einzelnes Verzeichnis verweisen. Sie können jedoch verschiedene Subdomains wiesubdomain.example.comverwenden, 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.
Damit die Verzeichnisse synchronisiert werden können, müssen zwischen den Active Directory-Domains und den von Cloud Identity oder Google Workspace 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 Nutzer in einer Active Directory-Gesamtstruktur identifiziert werden und wie sie Cloud Identity oder Google Workspace zugeordnet werden können.
Map users (Nutzer zuordnen)
Der dritte Faktor, den Sie beim Verbinden von Active Directory und Google Cloud berücksichtigen sollten, ist die Zuordnung von Nutzern zwischen Active Directory und Cloud Identity oder Google Workspace.
Nutzer in Active Directory identifizieren
Intern verwendet Active Directory zwei Kennzeichnungen, um Nutzer eindeutig zu identifizieren:
objectGUID: Diese global eindeutige ID wird bei der Erstellung eines Nutzers erzeugt und ändert sich nie.objectSID: Die SID wird für alle Zugriffsprüfungen verwendet. Innerhalb einer Domain ist diese ID eindeutig und stabil. Allerdings wird einem Nutzer 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 Nutzern:
UPN (
userPrincipalName): Die bevorzugte Methode zum Identifizieren eines Nutzers 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 Nutzer zu identifizieren. Trotzdem sind sie optional. Bei einigen Nutzern 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 Formatsdomain<var>user, wie incorp\johndoe. Obwohl diese Namen als veraltet gelten, werden sie weiterhin verwendet und sind die einzige obligatorische Kennzeichnung eines Nutzers.
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.
Nutzeridentitäten in Cloud Search zuordnen
Für die Zuordnung zwischen Active Directory- und Cloud Identity- oder Google Workspace-Nutzern sind für jeden Nutzer zwei Informationen erforderlich:
- Eine stabile, eindeutige ID, mit der Sie während der Synchronisierung verfolgen können, welcher Active Directory-Nutzer welchem Nutzer in Cloud Identity oder Google Workspace entspricht. Auf der AD-Seite ist die
objectGUIDfür diesen Zweck perfekt geeignet. - Eine E-Mail-Adresse, deren Domainteil einer primären, sekundären oder Aliasdomain Ihres Cloud Identity- oder Google Workspace-Kontos entspricht. Da diese E-Mail-Adresse in der gesamten Google Cloud verwendet wird, sollte Sie möglichst aussagekräftig sein. Eine aus der
objectGUIDabgeleitete Adresse ist ebenso unzweckmäßig wie andere automatisch generierte E-Mail-Adressen.
Für einen Active Directory-Nutzer sind zwei Felder geeignet, um eine Cloud Identity- oder Google Workspace-E-Mail-Adresse anzugeben: userPrincipalName und mail.
Nach User Principal Name (UPN) zuordnen
Wenn Sie das Feld userPrincipalName verwenden, müssen zwei Kriterien für alle zu synchronisierenden Nutzer erfüllt sein:
- UPNs (User Principal Names) 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 Nutzern muss ein UPN zugewiesen sein. Mit dem folgenden PowerShell-Befehl können Sie nach Nutzern suchen, die keinen UPN haben:
Get-ADUser -LDAPFilter "(!userPrincipalName=*)"
Wenn diese beiden Kriterien erfüllt sind, können Sie UPNs bedenkenlos E-Mail-Adressen von Cloud Identity oder Google Workspace zuordnen. Sie können eine der UPN-Suffixdomains als primäre Domain in Cloud Identity oder Google Workspace verwenden und alle anderen UPN-Suffixdomains als sekundäre Domains hinzufügen.
Ist eines der Kriterien nicht erfüllt, können Sie UPNs trotzdem Cloud Identity- oder Google Workspace-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 Google Cloud. Dadurch können den Nutzern wichtige Informationen entgehen.
- Nutzer 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 einziger Nutzer synchronisiert werden.
Die Zuordnung von Nutzern per UPN bietet 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
mailausgefüllt sein. Mit dem folgenden PowerShell-Befehl können Sie nach Nutzern 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 Nutzer 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 Nutzer 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 oder in Google Workspace nutzen.
Ist eines der Kriterien nicht erfüllt, können Sie dennoch E-Mail-Adressen zu Cloud Identity- oder Google Workspace-E-Mail-Adressen zuordnen. Dabei gelten dann folgende Einschränkungen:
- Nutzer ohne E-Mail-Adressen werden während der Synchronisierung ebenso ignoriert wie Nutzer mit E-Mail-Adressen, die Domains verwenden, die nicht dem Cloud Identity- oder Google Workspace-Konto zugeordnet sind.
- Wenn zwei Nutzer dieselbe E-Mail-Adresse verwenden, wird nur ein Nutzer 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 ein Nutzer synchronisiert.
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 IAM-Rollen an einzelne Nutzer zu vergeben, legen Sie verschiedene Gruppen fest, die allgemeine Rollen in Ihrer Organisation abbilden. Anschließend weisen Sie diese Gruppen einer Reihe von 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 Google Workspace migrieren. GCDS kann daher normale und dynamische Verteilergruppen verarbeiten. Bei der Identitäts- und Zugriffsverwaltung für Google Cloud spielen Verteilergruppen jedoch keine Rolle. Deshalb konzentriert sich dieser Artikel ausschließlich auf Sicherheitsgruppen.
Das Zuordnen von Gruppen zwischen Active Directory und Google Cloud ist optional. Nach der Einrichtung der Nutzerbereitstellung können Sie Gruppen direkt in Cloud Identity oder Google Workspace erstellen und verwalten. Active Directory bleibt also 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äts- und die Zugriffsverwaltung verwenden möchten, sollten Sie Sicherheitsgruppen aus Active Directory synchronisieren, statt sie in Cloud Identity oder Google Workspace zu verwalten. Bei diesem Ansatz können Sie IAM so einrichten, dass Sie den Zugriff auf Ressourcen in Google Cloud mithilfe von Gruppenmitgliedschaften in Active Directory steuern können.
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.
- 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 Nutzer 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 Nutzer 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 GCDS synchronisieren. Verwendet Ihre Active Directory-Gesamtstruktur mehrere Domains, wird durch den Typ einer Gruppe bestimmt, ob und wie sie mit Cloud Identity oder Google Workspace synchronisiert werden kann.
Da lokale und globale Domaingruppen 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 oder Google Workspace synchronisieren möchten. Das gilt insbesondere dann, wenn Sie GCDS 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 GCDS-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 GCDS-Instanz erforderlich.
Bevor Sie zu dem Schluss kommen, dass Sie mehrere GCDS-Instanzen benötigen, um mehrere Active Directory-Domains mit Cloud Identity oder Google Workspace 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
In den folgenden Abschnitten werden die Arten von Sicherheitsgruppen beschrieben, die in Active Directory verwendet werden.
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.
Gruppen in Cloud Identity und Google Workspace
In Cloud Identity und Google Workspace gibt es nur einen Gruppentyp. Gruppen in Cloud Identity und Google Workspace sind nicht auf den Bereich des Cloud Identity- oder Google Workspace-Kontos beschränkt, in dem sie definiert wurden. Stattdessen können sie Nutzer aus verschiedenen Cloud Identity- oder Google Workspace-Konten enthalten, in anderen Konten referenziert und verschachtelt werden sowie in jeder Google Cloud-Organisation zum Einsatz kommen.
Wie Nutzer werden Gruppen in Cloud Identity und Google Workspace anhand der E-Mail-Adresse identifiziert. Die E-Mail-Adresse muss nicht einem tatsächlichen Postfach entsprechen, jedoch eine der Domains verwenden, die für das jeweilige Cloud Identity-Konto registriert sind.
Im Gegensatz zu Active Directory-Gruppen erhalten Mitglieder einer Cloud Identity- oder Google Workspace-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 Google Cloud verwenden
Google Cloud 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 Google Cloud. Die Ressourcengruppen müssen außerdem nur selten mit Google Cloud synchronisiert werden.
Rollen- und Organisationsgruppen sind in Google Cloud 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.
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 GCDS-Instanz pro Gesamtstruktur mit mehreren Domains ausreicht oder ob Sie mehrere GCDS-Instanzen benötigen, sondern ob Sie globale Gruppen verwenden sollten. Wenn Sie alle Rollen- und Organisationsgruppen mithilfe von universellen Gruppen implementieren, reicht eine einzige GCDS-Instanz aus. Andernfalls benötigen Sie eine GCDS-Instanz pro Domain.
Gruppenidentitäten zuordnen
Für die Zuordnung von Active Directory-Sicherheitsgruppen zu Cloud Identity- oder Google Workspace-Gruppen ist eine gemeinsame Kennzeichnung erforderlich. In Cloud Identity und Google Workspace muss diese Kennzeichnung eine E-Mail-Adresse sein, deren Domainteil einer primären, sekundären oder Aliasdomain des Cloud Identity- oder Google Workspace-Kontos entspricht. Da diese E-Mail-Adresse überall in Google Cloud 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 geprüft.
Sie haben zwei Möglichkeiten, Gruppenidentitäten in Active Directory und Cloud Identity oder Google Workspace 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 GCDS so konfigurieren, dass automatisch ein Suffix an den Gruppennamen angehängt wird. Active Directory sorgt dafür, dass zwischen Gruppennamen und Nutzernamen 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 GCDS-Instanzen synchronisieren, spiegeln die E-Mail-Adressen, die vom allgemeinen Namen abgeleitet werden, nicht ihre Gesamtstruktur wider. Aufgrund dieser Mehrdeutigkeit löscht eine GCDS-Instanz Gruppen, die zuvor von einer anderen GCDS-Instanz aus einer anderen Gesamtstruktur erstellt wurden.
- Sie können Gruppen nicht nach allgemeinen Namen zuordnen, wenn Sie für die Zuordnung von Nutzern die Domainsubstitution verwenden.
Nach E-Mail-Adresse zuordnen
Wenn Sie Gruppenidentitäten anhand der E-Mail-Adresse (mail) zuordnen, müssen die gleichen Kriterien wie beim Zuordnen der Nutzer anhand der E-Mail-Adresse erfüllt werden:
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
mailausgefü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 Nutzer E-Mail-Adressen mit Domains von Partnerunternehmen oder privaten E-Mail-Anbietern enthalten, können Sie diese Adressen nicht verwenden.
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 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 oder Google Workspace registrierten DNS-Domains enthalten sind.
Ist eines der Kriterien nicht erfüllt, können Sie dennoch E-Mail-Adressen zu Cloud Identity- oder Google Workspace-E-Mail-Adressen zuordnen. Dabei 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- oder Google Workspace-Konto 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 Nutzer 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 Google Cloud haben Ordner und Projekte einen ähnlichen Zweck. Allerdings werden in einer Google Cloud-Organisation andere Ressourcenarten verwaltet als in Active Directory. Daher unterscheidet sich eine für ein Unternehmen geeignete Google Cloud-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 GCDS nicht unterstützt.
Unabhängig von den Ordnern unterstützen Cloud Identity und Google Workspace Organisationseinheiten. Organisationseinheiten werden ähnlich wie in Active Directory zum Gruppieren und Organisieren von Nutzern erstellt. Anders als bei Active Directory gelten sie jedoch nur für Nutzer, nicht für Gruppen.
GCDS bietet die Option, Organisationseinheiten von Active Directory mit Cloud Identity oder Google Workspace zu synchronisieren. In Umgebungen, in denen Cloud Identity lediglich zur Erweiterung der Active Directory-Identitätsverwaltung in Google Cloud verwendet wird, ist die Zuordnung von Organisationseinheiten normalerweise nicht erforderlich.
Die richtige Zuordnung auswählen
Wie bereits am Anfang dieses Dokuments erwähnt, gibt es keine allgemeingültige optimale Methode, um die Strukturen von Active Directory und Google Cloud 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- oder Google Workspace-Konten, GCDS-Instanzen und AD FS-Instanzen oder -Flotten Sie benötigen.
Im zweiten Diagramm finden Sie Informationen zur Identifizierung der Domains, die in Ihrem Cloud Identity- oder Google Workspace-Konto konfiguriert werden sollen.
Weitere Informationen
- Best Practices für die Planung von Konten und Organisationen und Best Practices für die Verbindung von Google Cloud mit einem externen Identitätsanbieter
- GCDS konfigurieren, um Active Directory-Nutzer und -Gruppen mit Cloud Identity zu synchronisieren
- Einmalanmeldung (SSO) zwischen Active Directory und Google Cloud konfigurieren
- Best Practices für die Verwaltung von Super Admin-Konten