Vom Kunden verwaltetes Active Directory (Customer-Managed Active Directory, CMAD) – Übersicht

Diese Seite enthält Informationen, die vor Beginn der Einbindung zu prüfen sind. Nachdem Sie die folgenden Informationen, einschließlich der Einschränkungen, gelesen haben, lesen Sie den Artikel Kundenverwaltetes Active Directory verwenden.

Sie können Cloud SQL for SQL Server in ein kundenverwaltetes Microsoft Active Directory (auch als kundenverwaltetes AD (CMAD) bezeichnet) einbinden.

Authentifizierung, Autorisierung und mehr sind über CMAD verfügbar. Wenn Sie beispielsweise eine Instanz mit einer CMAD-Domain verknüpfen, können Sie sich über die Windows-Authentifizierung mit einer AD-basierten Identität anmelden. Die Einbindung von Cloud SQL for SQL Server in eine AD-Domain hat den zusätzlichen Vorteil der Google Cloud Einbindung in Ihre lokalen AD-Domains.

Hinweis

Sie können die Einbindung in CMAD vornehmen, dabei einer Instanz Unterstützung für die Windows-Authentifizierung hinzufügen. Bevor Sie die Einbindung ausführen, benötigen Sie jedoch Folgendes für Ihr Google Cloud Projekt:

  • Damit die Authentifizierung funktioniert, müssen Ihre Cloud SQL-Instanzen eine Netzwerkverbindung zu allen relevanten Active Directory-Domains haben. Dazu gehören die primäre Domain, der die Instanz beitritt, sowie alle vertrauenswürdigen oder untergeordneten Domains, die Nutzer enthalten, die auf Cloud SQL for SQL Server zugreifen müssen. Dazu müssen die folgenden Ports (sowohl TCP als auch UDP) zwischen Ihren Cloud SQL-Instanzen und allen Ihren Domaincontrollern geöffnet sein: 53, 88, 135, 389, 445, 464, 3268, 3269 und 49152 bis 65535.
  • Sie müssen eine Organisationseinheit (OU) erstellen , um alle zugehörigen Einbindungsobjekte zu speichern.
    • In dieser Organisationseinheit müssen Sie dem Administratorkonto auch die folgenden Berechtigungen delegieren:
      • Computerobjekte verwalten (Objekt erstellen/Objekt löschen/Objekteigenschaften ändern)
      • Nutzerobjekte verwalten (Objekt erstellen/Objekt löschen/Objekteigenschaften ändern)
    • Wir empfehlen außerdem, diesem Administratorkonto Berechtigungen zum Verwalten von DNS-Einträgen zu gewähren, indem Sie es beispielsweise der Gruppe „DnsAdmins“ hinzufügen.

      Wenn Sie diese Berechtigungen nicht gewähren, wird die Einbindung trotzdem erfolgreich ausgeführt. Für die Verbindung zu Ihrer Instanz müssen Sie jedoch die erforderlichen DNS-Einträge manuell erstellen, wie unter Verbindung zu einer Instanz mit einem Nutzer herstellen beschrieben.

      Alternativ können Sie eine Verbindung über die IP-Adresse der Instanz herstellen. Dies ist jedoch mit Einschränkungen verbunden und funktioniert nicht für Verbindungen von vertrauenswürdigen Domains.

  • Sie müssen Ihre Administratoranmeldedaten in einem Secret Manager-Secret im folgenden JSON-Format speichern: 
        {
      "credentials": [
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_1",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_1"
        },
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE_2",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_2",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_2"
        }
      ]
    }

    Ersetzen Sie Folgendes:

    • VALID_AFTER_UTC_VALUE_1: Der erste UTC-Wert, den Sie verwenden möchten, im Format YYYY-MM-DDThh:mm:ssZ. Ein Beispiel wäre 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_1: Die erste Administratoranmeldung, die Sie verwenden möchten, z. B. myadmin. Fügen Sie den Domain namen nicht in den Wert ein. Einträge wie myadmin@my-domain-name.com werden nicht unterstützt.
    • ADMINISTRATOR_PASSWORD_VALUE_1: Das Administratorkennwort.
    • VALID_AFTER_UTC_VALUE_2: Der zweite UTC-Wert, den Sie verwenden möchten, im Format YYYY-MM-DDThh:mm:ssZ. Ein Beispiel wäre 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_2: Die zweite Administratoranmeldung, die Sie verwenden möchten, z. B. myadmin2. Fügen Sie auch hier den Domain namen nicht in den Wert ein. Einträge wie myadmin2@my-domain-name.com werden nicht unterstützt.
    • ADMINISTRATOR_PASSWORD_VALUE_2: Das Kennwort des zweiten Administrators.

    Diese Datei kann mehrere Anmeldedateneinträge enthalten, um Probleme mit langsamer Weitergabe zu vermeiden oder geplante, im Voraus durchgeführte Rotationen zu berücksichtigen.

    Das Feld validAfterUTC ist optional. Wenn es nicht angegeben ist, wird davon ausgegangen, dass die Anmeldedaten immer gültig sind. Wir empfehlen, diese Anmeldedaten dauerhaft in Secret Manager verfügbar zu halten und die Automatisierung zu verwenden, um das Kennwort zu aktualisieren, wenn Sie die Anmeldedaten rotieren.

    Sie können das Secret nach der Instanzerstellung löschen. Beachten Sie jedoch, dass zukünftige Vorgänge wie das Klonen oder Hinzufügen eines Lesereplikats dazu führen, dass die neue Instanz nicht der Domain beigetreten wird.

    Wenn Sie außerdem die ursprüngliche Instanz löschen, bleiben verwaiste Objekte wie das Computerkonto in Ihrem CMAD zurück.

  • Halten Sie eine Liste der DNS-Server-IP-Adressen für Ihr kundenverwaltetes Active Directory bereit. Das sind in der Regel Ihre Domaincontroller. Wir empfehlen, für diese Server statische IP-Adressen zu verwenden.
  • Weisen Sie produkt- und projektspezifische Dienstkonten zu.

Dienstkonto erstellen und konfigurieren

So erstellen Sie ein Dienstkonto mit den erforderlichen Berechtigungen:

Führen Sie den folgenden Befehl aus, um ein Dienstkonto mit der gcloud CLI zu erstellen:

  gcloud beta services identity create --service=sqladmin.googleapis.com 

      --project=PROJECT_ID

Dieser Befehl gibt den Namen eines Dienstkontos im folgenden Format zurück:

  service-PROJECT_ID@gcp-sa-cloud-sql.iam.gserviceaccount.com

Hier ist ein Beispiel für einen Dienstkontonamen:

  service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com

Führen Sie den folgenden Befehl aus, um die erforderliche Berechtigung für die Einbindung zu erteilen:

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 

    --permissions="secretmanager.secrets.getIamPolicy,secretmanager.secrets.setIamPolicy"

Führen Sie dann den folgenden Befehl aus:

  gcloud secrets add-iam-policy-binding ADCredentials --project="722300452883" 

    --member="serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com" 

    --role="projects/PROJECT-ID/roles/secretIamPolicyManager"

Weitere Informationen finden Sie unter gcloud beta services identity create.

Best Practices für die Einbindung in CMAD

Bei der Einbindung in CMAD empfehlen wir, die folgenden Schritte auszuführen.

Voraussetzungen für die Einbindung

Verwenden Sie das Active Directory-Diagnosetool um Probleme bei der AD-Einrichtung mit Ihrer lokalen Domain und Cloud SQL for SQL Server Instanzen in der Google Cloud Console zu beheben. Überspringen Sie die Schritte im Zusammenhang mit Managed Service for Microsoft Active Directory.

Topologien für die Einbindung in CMAD

Cloud SQL for SQL Server unterstützt keine lokalen Domaingruppen. Es gibt jedoch folgende Alternativen:

  • Globale Gruppen oder einzelne Nutzeranmeldungen direkt in SQL Server hinzufügen.
  • Verwenden Sie universelle Gruppen, wenn alle Gruppen und Nutzer derselben Gesamtstruktur angehören.

Cloud SQL for SQL Server unterstützt keine lokalen Domaingruppen als Anmeldungen. Wenn Sie Domainnutzern Berechtigungen gewähren möchten, müssen Sie stattdessen globale oder universelle Gruppen verwenden, wie in diesem Abschnitt beschrieben.

Option 1: Nutzerkonten und -gruppen als Anmeldungen zu SQL Server hinzufügen

Wenn Sie mehrere Domains in mehreren Gesamtstrukturen und mehrere globale Gruppen haben, können Sie alle einzelnen Nutzerkonten sowie die globalen und universellen Gruppen direkt als Anmeldungen zu SQL Server hinzufügen. Ein Beispiel für Option 1 finden Sie im folgenden Diagramm:

CMAD-Topologie, Option 1.

Option 2: Universelle Gruppe in einer Ihrer Domains definieren

Wenn sich Ihre Domains in derselben Gesamtstruktur befinden, können Sie eine universelle Gruppe in einer Ihrer Domains definieren. Anschließend können Sie alle einzelnen Nutzerkonten sowie die globalen und universellen Gruppen als untergeordnete Elemente dieser definierten Gruppe hinzufügen und die definierte universelle Gruppe als SQL Server-Anmeldung hinzufügen. Ein Beispiel für Option 2 finden Sie im folgenden Diagramm:

CMAD-Topologie, Option 2

Einschränkungen und Alternativen

Die folgenden Einschränkungen gelten bei der Einbindung in CMAD:

  • Cloud SQL for SQL Server-Instanzen, die Private Service Connect (PSC) für private Verbindungen verwenden, werden nicht unterstützt. Verwenden Sie stattdessen den Zugriff auf private Dienste (Private Services Access, PSA).
  • Lokale Domaingruppen werden nicht unterstützt. Sie können aber globale Gruppen oder individuelle Nutzeranmeldungen direkt in SQL Server hinzufügen. Alternativ können Sie universelle Gruppen verwenden, wenn alle Gruppen und Nutzer derselben Gesamtstruktur angehören.
  • Wenn es weitere vertrauenswürdige Domains gibt und Sie mit Nutzernamen von dort auf SQL Server Instanzen zugreifen möchten, müssen sie über eine bidirektionale Vertrauensstellung verbunden sein. Unidirektionale und externe Vertrauensstellungen werden nicht unterstützt.
  • Im Allgemeinen wird neuen Nutzern, die über die Google Cloud Console erstellt werden, die CustomerDbRootRole Rolle zugewiesen, die diese feste Datenbankrolle des SQL Server-Agent hat: SQLAgentUserRole. Nutzer, die direkt über SQL Server erstellt wurden, z. B. CMAD-Nutzer, können diese Rolle jedoch nicht erhalten oder den SQL Server-Agent verwenden, da die MSDB-Datenbank, für die diese Rolle gewährt werden muss, geschützt ist.
  • Vollständig qualifizierte Domainnamen (Fully Qualified Domain Names, FQDNs) werden von SQL Server nicht unterstützt. Verwenden Sie daher beim Erstellen von SQL Server-Anmeldungen Domainnamen (Kurznamen) anstelle von FQDNs. Wenn Ihr Domainname beispielsweise ad.mydomain.com, lautet, erstellen Sie SQL Server-Anmeldungen für ad\user statt für ad.mydomain.com\user.
  • Verwenden Sie zum Zugriff auf SQL Server-Instanzen immer die FQDNs. Beispielsweise können Sie einen FQDN ähnlich wie private.myinstance.us-central1.myproject.cloudsql.mydomain.com verwenden. Netbios-Namen werden nicht unterstützt, auch keine Kurznamen, wenn DNS-Suffixe weggelassen werden.
  • SQL Server-Anmeldungen, die auf Active Directory-Nutzern und -Gruppen basieren, können nicht über die Google Cloud Console verwaltet werden.
  • Die Windows-Authentifizierung funktioniert nicht mit einer externen Vertrauensstellung. Der zurückgegebene Fehler kann so aussehen: 
      "The target principal name is incorrect. Cannot generate SSPI context."
    Verwenden Sie außerdem laut Microsoft-Empfehlungen, eine Gesamtstruktur-Vertrauensstellung statt einer externen Vertrauensstellung für die Kerberos-Authentifizierung.
  • Es wird immer die aktuelle Version des Secrets verwendet. Das Secret muss aktiv sein und kann nicht zerstört werden.

Active Directory-Endpunkte und TLS-Verbindungen

Wenn Sie die Windows-Authentifizierung verwenden und eine TLS-Verbindung herstellen möchten, ohne das Serverzertifikat zu vertrauen, müssen Sie die Zertifikate rotieren, nachdem die Windows-Authentifizierung für die Instanz aktiviert wurde.

Wenn die Verbindung fehlschlägt und eines Ihrer Zertifikate vor dem 15. März 2025 erstellt wurde, müssen Sie das Serverzertifikat noch einmal rotieren und die Verbindung noch einmal versuchen.

Einbindung nicht unterstützt

Die folgenden Features werden bei einer Einbindung in CMAD nicht unterstützt:

  • Lokale Domaingruppen.
  • NTLM-Authentifizierung
  • Melden Sie sich mit einer IP-Adresse aus Domains an, die über eine Vertrauensstellung verbunden sind.
  • Instanzen mit langen Namen (mehr als 63 Zeichen).

Monitoring

Mit dem folgenden Messwert können Sie den Status und die Integrität von CMAD überwachen:

cloudsql.googleapis.com/database/active_directory/domain_reachable

Dieser Messwert gibt an, ob das CMAD von der Cloud SQL-Instanz aus erreichbar ist. Er ist ein nützliches Tool zur Behebung von Netzwerkproblemen:

cloudsql.googleapis.com/database/active_directory/instance_available

Nächste Schritte