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 die Informationen unter Vom Kunden verwaltetes Active Directory verwenden.

Sie können Cloud SQL for SQL Server in vom Kunden verwaltetes Microsoft Active Directory (auch als vom Kunden verwaltetes 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.

Hinweise

Sie können die Einbindung in CMAD vornehmen und 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 IhrGoogle 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 erstellen, in der alle zugehörigen Integrationsobjekte gespeichert werden.
    • In dieser Organisationseinheit benötigen Sie außerdem ein Administratorkonto mit den folgenden Berechtigungen:
      • Computerobjekte erstellen
      • Computerobjekte löschen
      • Nutzerobjekte erstellen
      • Nutzerobjekte löschen
      • Alle Eigenschaften schreiben
      • Passwort zurücksetzen
      • Sperrzeit für Lesezugriff, Sperrzeit für Schreibzugriff
    • Wir empfehlen außerdem, diesem Administratorkonto Berechtigungen zum Verwalten von DNS-Einträgen zu gewähren, z. B. durch Hinzufügen zur Gruppe „DnsAdmins“.

      Wenn Sie diese Berechtigungen nicht erteilen, wird die Integration 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 dafür ist 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_1: die erste Administratoranmeldung, die Sie verwenden möchten, z. B. myadmin. Geben Sie den Domainnamen nicht im Wert an. Einträge wie myadmin@my-domain-name.com werden nicht unterstützt.
    • ADMINISTRATOR_PASSWORD_VALUE_1: Das Administratorpasswort.
    • VALID_AFTER_UTC_VALUE_2: Der zweite UTC-Wert, den Sie verwenden möchten, im Format YYYY-MM-DDThh:mm:ssZ. Ein Beispiel dafür ist 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_2: Die Anmeldedaten des zweiten Administrators, die Sie verwenden möchten, z. B. myadmin2. Ebenso darf der Domainname nicht im Wert enthalten sein. Einträge wie myadmin2@my-domain-name.com werden nicht unterstützt.
    • ADMINISTRATOR_PASSWORD_VALUE_2: Das Passwort des zweiten Administrators.

    Diese Datei kann mehrere Anmeldedateneinträge enthalten, um Probleme mit der langsamen Weitergabe zu beheben 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 das Passwort automatisch zu aktualisieren, wenn Sie die Anmeldedaten rotieren.

    Sie können das Secret nach dem Erstellen der Instanz löschen. Beachten Sie jedoch, dass bei zukünftigen Vorgängen wie dem Klonen oder Hinzufügen eines Lesereplikats die neue Instanz nicht der Domain beigetreten wird.

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

  • Sie haben eine Liste der DNS-Server-IP-Adressen für Ihr vom Kunden verwaltetes Active Directory, bei denen es sich in der Regel um Ihre Domaincontroller handelt. Wir empfehlen, für diese Server statische IP-Adressen zu verwenden.
  • Weisen Sie Dienstkonten pro Produkt und Projekt zu.

Dienstkonto erstellen und konfigurieren

Prüfen Sie Folgendes, um ein Dienstkonto mit den erforderlichen Berechtigungen zu erstellen:

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 Integration mit CMAD

Wir empfehlen, bei der Integration mit CMAD 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, die sich auf Managed Service for Microsoft Active Directory beziehen.

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 erteilen 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

Bei der Einbindung in CMAD gelten die folgenden Einschränkungen:

  • 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 einzelne 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 zusätzliche vertrauenswürdige Domains gibt und Sie mit Nutzernamen von dort aus auf SQL Server-Instanzen zugreifen möchten, müssen diese über eine bidirektionale Vertrauensstellung verbunden sein. Einseitige und externe Vertrauensstellungen werden nicht unterstützt.
  • Im Allgemeinen wird neuen Nutzern, die über die Google Cloud Konsole erstellt werden, die Rolle CustomerDbRootRole 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 (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 -Konsole verwaltet werden.
  • Die Windows-Authentifizierung funktioniert nicht mit einer externen Vertrauensstellung. Der zurückgegebene Fehler könnte 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 darf nicht zerstört werden.

Active Directory-Endpunkte und TLS-Verbindungen

Wenn Sie die Windows-Authentifizierung verwenden und eine TLS-Verbindung herstellen möchten, ohne dem 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 Funktionen 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 den Zustand 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. Es ist ein nützliches Tool zur Behebung von Netzwerkproblemen:

cloudsql.googleapis.com/database/active_directory/instance_available

Nächste Schritte