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,3269und49152bis65535. - 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.
- In dieser Organisationseinheit benötigen Sie außerdem ein Administratorkonto mit den folgenden Berechtigungen:
- 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 ist2099-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 wiemyadmin@my-domain-name.comwerden 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 ist2099-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 wiemyadmin2@my-domain-name.comwerden 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
validAfterUTCist 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.
- VALID_AFTER_UTC_VALUE_1: Der erste UTC-Wert, den Sie verwenden möchten, im Format
- 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:
- Sie müssen die Cloud SQL Admin API aktivieren.
- Sie benötigen die folgenden Berechtigungen:
- resourcemanager.projects.setIamPolicy
- secretmanager.secrets.getIamPolicy
- secretmanager.secrets.setIamPolicy
Sie benötigen für jedes Projekt, das Sie in CMAD integrieren möchten, ein produkt- und projektbasiertes Dienstkonto. Verwenden Sie die gcloud CLI, um das Konto auf Projektebene zu erstellen. Dem Dienstkonto pro Produkt und Projekt müssen die Berechtigungen
secretmanager.secrets.getIamPolicyundsecretmanager.secrets.setIamPolicyfür das im vorherigen Schritt erstellte Secret zugewiesen werden. Weitere Informationen finden Sie unter Secret Manager-Berechtigungen.Wir empfehlen, eine benutzerdefinierte Rolle 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:

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:

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
CustomerDbRootRolezugewiesen, 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.comlautet, erstellen Sie SQL Server-Anmeldungen fürad\userstatt fürad.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.comverwenden. 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:
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