Managed Microsoft AD mit Cloud SQL verwenden

Auf dieser Seite wird beschrieben, wie Sie Cloud SQL für folgende Aufgaben verwenden:

• Einbindung in Managed Service for Microsoft Active Directory (auch Managed Microsoft AD genannt) vornehmen
• Verbindung zu einer Instanz mit einem AD-Nutzer herstellen

Eine Cloud SQL-Instanz, die in Managed Microsoft AD eingebunden ist, unterstützt zusätzlich zur SQL-Authentifizierung die Windows-Authentifizierung.

Vorbereitung

1. Wählen Sie in der Google Cloud Console den Projektnamen aus.
2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein. So bestätigen Sie die Abrechnung für Ihr Projekt.
3. Installieren und initialisieren Sie die gcloud CLI.
4. Sie benötigen die Cloud SQL Admin-Rolle für Ihr Nutzerkonto. Rufen Sie die IAM-Seite auf.
5. Prüfen Sie die Voraussetzungen für die Einbindung.

Instanz mit der Windows-Authentifizierung erstellen

Sie können die Einbindung in Managed Microsoft AD während der Instanzerstellung vornehmen. Dadurch wird die Windows-Authentifizierung für die Instanz aktiviert. Zur Einbindung wählen Sie eine Domain aus, mit der diese Instanz verknüpft wird. Wenn die Verknüpfung mit einer Domain fehlschlägt, schlägt die Instanzerstellung fehl.

Lesen Sie vor dem Erstellen einer Instanz mit der Windows-Authentifizierung die Tipps sowie die Einschränkungen und Alternativen.

Eine Instanz mit öffentlicher IP-Adresse wird unterstützt, sofern sie auch eine private IP-Adresse hat. Private IP-Adressen müssen für die Instanz aktiviert sein. Sie können dann über eine öffentliche IP-Adresse oder eine private IP-Adresse eine Verbindung zur Instanz herstellen, sofern beide verfügbar sind.

Im Folgenden sind die Optionen zum Erstellen einer Instanz aufgeführt, die in Managed Microsoft AD eingebunden ist.

gcloud beta sql instances create INSTANCE_NAME \
--database-version=EDITION \
--root-password=PASSWORD \
--active-directory-domain=DOMAIN\
--cpu=CPU \
--memory=MEMORY  \
--network=NETWORK

resource "google_sql_database_instance" "instance_with_ad" {
  name             = "database-instance-name"
  region           = "us-central1"
  database_version = "SQLSERVER_2019_STANDARD"
  root_password    = "INSERT-PASSWORD-HERE"

  depends_on = [google_service_networking_connection.private_vpc_connection]

  settings {
    tier = "db-custom-2-7680"
    active_directory_config {
      domain = "ad.domain.com"
    }
    ip_configuration {
      ipv4_enabled    = "false"
      private_network = google_compute_network.private_network.id
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

{
   "databaseVersion":"database-version",
   "name":"instance-id",
   "region":"region",
   "rootPassword":"password",
   "settings":{
      "tier":"machine-type",
      "ipConfiguration":{
         "privateNetwork":"network"
      },
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

Instanz mit der Windows-Authentifizierung aktualisieren

Sie können die Domain einer vorhandenen Instanz aktualisieren, d. h. sie können sie ändern oder eine Domain hinzufügen.

Allgemeine Informationen zum Aktualisieren einer Instanz finden Sie unter Instanzen bearbeiten.

Wenn eine Instanz bereits mit einer verwalteten AD-Domain verknüpft ist, wird die Instanz erst einmal aus dieser Domain entfernt, bevor sie mit der neuen Domain verknüpft wird. Wenn die Aktualisierung fehlschlägt, kann die Instanz nicht mehr mit einer Domain verknüpft werden.

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=DOMAIN

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

In eine verwaltete AD-Domain in einem anderen Projekt einbinden

Sie können Ihre Instanz in eine Managed Microsoft AD-Domain einbinden, die sich in einem anderen Projekt befindet.

Sehen Sie sich bei der Planung der Integration die Einschränkungen an.

Domain-Peering aktivieren

Bevor Sie mit den Schritten in den folgenden Abschnitten fortfahren, aktivieren Sie das Domain-Peering, damit Ihre Domain für alle erforderlichen Projekte mit Cloud SQL for SQL Server-Instanzen verfügbar ist.

Für eine Liste von Domains aus anderen Projekten, die bereits verfügbar sind, können Sie Folgendes angeben:

`gcloud active-directory peerings list`

Weitere Informationen finden Sie unter Domain-Peerings auflisten.

Für den Befehl gcloud active-directory peerings list ist die Berechtigung managedidentities.peerings.list erforderlich. Die folgenden Rollen haben diese Berechtigung:

• roles/managedidentities.peeringViewer
• roles/managedidentities.viewer

Weitere Informationen finden Sie unter Zugriffssteuerung mit IAM.

Dienstkonto erstellen

Wiederholen Sie diese Schritte für jedes Projekt, das eine Cloud SQL for SQL Server-Instanz enthält, die Sie integrieren möchten.

1. Lesen Sie sich die Hintergrundinformationen zum Erstellen von Dienstkonten durch.

2. Verwenden Sie zum Erstellen eines Dienstkontos einen ähnlichen Befehl wie den folgenden. Geben Sie die ID des Projekts an, das Cloud SQL for SQL Server-Instanzen enthält:

   gcloud beta services identity create --service=sqladmin.googleapis.com \
   --project=[PROJECT_ID]

3. Weisen Sie die Rolle managedidentities.sqlintegrator im Projekt mit der Managed Microsoft AD-Instanz zu. Geben Sie die ID des Projekts an, das die Managed Microsoft AD-Instanz enthält:

   gcloud projects add-iam-policy-binding [PROJECT_ID] \
   --member=serviceAccount:SERVICE_ACCOUNT --role=roles/managedidentities.sqlintegrator

Projektübergreifende Windows-Authentifizierung aktivieren

Sie können eine AD-Domain mithilfe von gcloud-Befehlen oder der Cloud SQL REST API in ein anderes Projekt integrieren. In beiden Fällen müssen Sie den vollständigen Namen der Domainressource angeben.

Geben Sie den vollständigen Domainressourcennamen an, wenn eine Cloud SQL for SQL Server-Instanz erstellt oder aktualisiert wird. Es werden zwei Formate unterstützt:

• projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME
• projects/PROJECT_NUMBER/locations/global/domains/DOMAIN_NAME

Hier ein Beispiel mit gcloud:

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME

Wenn Sie einen kurzen Domainressourcennamen verwenden (z. B. DOMAIN_NAME), geht das System davon aus, dass sich Ihre Managed Microsoft AD-Domain im selben Projekt wie Ihre Cloud SQL for SQL Server-Instanzen befindet.

Einschränkungen bei der Einbindung in verschiedene Projekte

Wenn Sie eine verwaltete AD-Domain in einem anderen Projekt einbinden, gelten die folgenden Einschränkungen:

• Bis zu 10 Netzwerke mit Cloud SQL for SQL Server-Instanzen können eine Managed Microsoft AD-Instanz gemeinsam nutzen, die sich in einem anderen Projekt befindet.
• Die Google Cloud Console unterstützt nur Managed Microsoft AD-Instanzen, die im selben Projekt sind. Anstatt die Google Cloud Console zu verwenden, können Sie mit gcloud-Befehlen oder der Cloud SQL REST API integrieren.
• Wenn VPC Service Controls verwendet wird, müssen sich Cloud SQL for SQL Server-Instanzen und eine Managed Microsoft AD-Instanz im selben Perimeter befinden.

Wenn eine Instanz in eine verwaltete AD-Domain in einem anderen Projekt integriert ist, ist der in der Google Cloud Console angezeigte vollständig qualifizierte Domainname (FQDN) für diese Instanz möglicherweise fehlerhaft. Insbesondere auf der Seite Übersicht für diese Instanz unter Mit dieser Instanz verbinden können die FQDNs Strings enthalten, die durch Schrägstriche getrennt sind. Dies können Sie ignorieren. Ein fehlerhafter FQDN könnte beispielsweise so aussehen:

private.myinstance.myregion.myproject.projects/mydirectory/locations/global/domains/mydomain.com

In diesem Fall lautet der richtige FQDN:

private.myinstance.myregion.myproject.cloudsql.mydomain.com

Windows-Authentifizierung aus einer Instanz entfernen

Sie können die Windows-Authentifizierung und damit eine Managed Microsoft AD-Einbindung von einer vorhandenen Instanz entfernen.

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":""
      }
   }
}

Verbindung zu einer Instanz mit einem Nutzer herstellen

Bei Cloud SQL for SQL Server, ist der Standardnutzer sqlserver.

Nachdem Sie eine Instanz in Managed Microsoft AD eingebunden haben, können Sie mit dem Nutzer sqlserver eine Verbindung zur Instanz herstellen:

1. Erstellen Sie so ein SQL Server-Login auf Basis eines Windows-Nutzers oder einer Windows-Gruppe:

   CREATE LOGIN [domain\user_or_group] FROM WINDOWS

2. Melden Sie sich über die Windows-Authentifizierung mit dem Instanz-DNS-Namen bei der Instanz an. Beispiele zur Angabe von DNS-Namen für Instanzen:

   • So stellen Sie eine Verbindung über eine private IP-Adresse her:

     private.myinstance.us-central1.myproject.cloudsql.mydomain.com

   • So stellen Sie eine Verbindung über eine öffentliche IP-Adresse her:

     public.myinstance.us-central1.myproject.cloudsql.mydomain.com

   • Verbindung über den Cloud SQL Auth-Proxy herstellen (siehe unten):

     proxy.myinstance.us-central1.myproject.cloudsql.mydomain.com

   Wenn Sie die Instanz-IP-Adresse verwenden, müssen Sie die Kerberos-Clients so konfigurieren, dass sie IP-Hostnamen unterstützen. Cloud SQL unterstützt Anmeldungen von Domains, die über eine Vertrauensstellung verbunden sind, nicht.

Cloud SQL Auth-Proxy mit Windows-Authentifizierung verwenden

Sie können den Cloud SQL Auth-Proxy mit Ihrer Managed Microsoft AD-Einbindung verwenden.

Bevor Sie beginnen, lesen Sie Folgendes:

• Informationen zum Cloud SQL Auth-Proxy

• Über den Cloud SQL Auth-Proxy verbinden

Schritte für die Windows-Authentifizierung

Informationen zum Starten des Cloud SQL Auth-Proxys finden Sie unter Cloud SQL Auth-Proxy starten.

Für die Windows-Authentifizierung müssen Sie den Cloud SQL Auth-Proxy auf Port 1433 ausführen. So ordnen Sie einer Cloud SQL Auth-Proxy-Adresse einen vordefinierten Dienstprinzipalnamen (Service Principal Name, SPN) zu:

proxy.[instance].[location].[project].cloudsql.[domain]

Cloud SQL Auth-Proxy lokal ausführen

Wenn Sie den Cloud SQL Auth-Proxy lokal ausführen, ordnen Sie mit Ihrer Hostdatei Folgendes zu 127.0.0.1 zu:

proxy.[instance].[location].[project].cloudsql.[domain]

Beispielsweise können Sie der Hostdatei Folgendes hinzufügen (z. B. zu c:\windows\system32\drivers\etc\hosts):

127.0.0.1 proxy.[instance].[location].[project].cloudsql.[domain]

In diesem Beispiel könnten Sie den Cloud SQL Auth-Proxy mit diesem Befehl ausführen und auf 127.0.0.1:1433 verfügbar machen:

cloud-sql-proxy.exe --credentials-file credential.json project:name

Cloud SQL Auth-Proxy nicht lokal ausführen

Wenn Sie den Cloud SQL Auth-Proxy nicht lokal ausführen möchten, folgen Sie der Anleitung unter Cloud SQL Auth-Proxy lokal ausführen, aber verwenden Sie einen anderen Eintrag in der Hostdatei.

Wenn z. B. ein nicht lokaler Host beispielsweise MyOtherHost lautet, können Sie der Hostdatei Folgendes hinzufügen:

127.0.0.1 MyOtherHost proxy.[instance].[location].[project].cloudsql.[domain]

Fehlerbehebung für NTLM-Fallback in Clients

Wenn Sie die Windows-Authentifizierung und eine Instanz-IP-Adresse verwenden, um sich bei einer Instanz anzumelden, müssen Sie einen Kerberos-Client für die Unterstützung von IP-Hostnamen konfigurieren.

Cloud SQL unterstützt die NTLM-Authentifizierung nicht. Es kann jedoch vorkommen, dass einige Kerberos-Clients versuchen, darauf zurückzugreifen. Wie in diesem Abschnitt erläutert, wird möglicherweise wegen eines NTLM-Fallback die folgende Fehlermeldung angezeigt, wenn Sie versuchen, eine Verbindung zu SQL Server Management Studio (SSMS) herzustellen:

Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. (Microsoft SQL Server, Error: 18452)

NTLM besteht aus einer Reihe von Microsoft-Sicherheitsprotokollen für die Authentifizierung. Siehe auch Gründe für NTLM-Fallback.

Überprüfung eines NTLM-Fallbacks für einen Windows-Client

So prüfen Sie unter Windows, ob ein NTLM-Fallback einen Fehler verursacht hat:

1. Melden Sie sich mit den gewünschten lokalen Anmeldedaten an. Verwenden Sie nicht „Ausführen als...“.
2. Öffnen Sie die Eingabeaufforderung.
3. Führen Sie klist purge aus.
4. Versuchen Sie in SSMS, mit Windows-Authentifizierung eine Verbindung zu SQL Server herzustellen.
5. Führen Sie klist aus und prüfen Sie, ob ein Ticket für "MSSQLSvc/<address>:1433 @ domain" vorliegt.
6. Wenn kein solches Ticket vorhanden ist, ist wahrscheinlich ein NTLM-Fallback die Ursache für den Fehler.
7. Wenn ein solches Ticket vorhanden ist, kontrollieren Sie, dass der SQL Server-Treiber nicht die NTLM-Authentifizierung erzwingt. Prüfen Sie auch, ob die NTLM-Authentifizierung über die Gruppenrichtlinie erzwungen wird.

Überprüfung eines NTLM-Fallbacks für einen Linux-Client

Führen Sie die Schritte in diesem Abschnitt aus, um unter Ubuntu 16.04 zu kontrollieren, dass ein NTLM-Fallback einen Fehler verursacht hat. Die Schritte sind ähnlich wie bei anderen Linux-Distributionen.

Kerberos-Authentifizierung einrichten

1. Richten Sie einen Kerberos-Client ein:

   sudo apt-get install krb5-user
   

2. Wenn Sie zur Eingabe des Standardbereichs aufgefordert werden, geben Sie einen lokalen Domainnamen in Großbuchstaben ein.

3. Führen Sie den folgenden Befehl aus, um die SQL Server-Befehlszeilentools zu installieren:

   curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
   curl https://packages.microsoft.com/config/ubuntu/16.04/prod.list | sudo tee /etc/apt/sources.list.d/msprod.list
   sudo apt-get update
   sudo apt-get install mssql-tools unixodbc-dev
   

Mit Windows-Authentifizierung verbinden

1. Führen Sie das kinit-Tool so aus: kinit <user_account>.
2. Zum Herstellen einer Verbindung zur Windows-Authentifizierung führen Sie folgenden Befehl aus: /opt/mssql-tools/bin/sqlcmd -S <address >>.
3. Führen Sie den Befehl klist aus und prüfen Sie, ob ein Ticket speziell für "MSSQLSvc/<address>:1433 @ domain" ausgegeben wurde.
4. Wenn das Ticket nicht ausgestellt wurde, weist der obige Fehler wahrscheinlich auf ein Problem hin, das einen NTLM-Fallback verursacht.

Gründe für NTLM-Fallback

Ein Fallback auf NTLM ist eine Client-Fehlkonfiguration, die mit den folgenden Merkmalen verknüpft sein kann:

• Standardmäßig versucht Windows nicht, die Kerberos-Authentifizierung für einen Host zu verwenden, wenn der Hostname eine IP-Adresse ist. Mit der in der Microsoft-Dokumentation beschriebenen Methode können Sie die Kerberos-Authentifizierung über die verwaltete Domain aktivieren. Diese Methode funktioniert nicht mit lokalen Anmeldedaten, wenn FQDNs verwendet werden müssen.
• Die Kerberos-Authentifizierung über externe Vertrauensstellungen funktioniert nicht. Verwenden Sie stattdessen Gesamtstruktur-Vertrauensstellungen, wie hier beschrieben.
• Für die Kerberos-Authentifizierung ist das Namenssuffix-Routing erforderlich, um das Auffinden von Diensten in einer anderen Gesamtstruktur zu ermöglichen. Probieren Sie die hier beschriebene Methode aus.
• Die Kerberos-Authentifizierung funktioniert nicht, wenn kein SPN für den Dienst registriert ist. Verwenden Sie nur von der Google Cloud Console abgerufene FQDNs oder IP-Adressen, um Verbindungen zur Windows-Authentifizierung herzustellen.

Lokale AD-Nutzer: Windows-Anmeldung erstellen

Sie können einen lokalen AD-Nutzer verwenden, wenn Sie eine Windows-Anmeldung bei Cloud SQL for SQL Server erstellen möchten.

Beispielsweise haben Sie die Möglichkeit, eine Verbindung zu SQL Server Management Studio (SMSS) herzustellen, das auf einer Windows-VM ausgeführt wird, die in der Virtual Private Cloud (VPC) Ihres Google Cloud-Projekts gehostet wird.

Für die Windows-Authentifizierung in diesem Kontext unterstützt Cloud SQL for SQL Server nur das Kerberos-Protokoll. Für die Kerberos-basierte Windows-Authentifizierung muss der Client den DNS-Namen der lokalen AD- und der Managed Microsoft AD auflösen.

Einseitige oder bidirektionale Vertrauensstellung konfigurieren

Entscheiden Sie zuerst, ob eine einseitige oder bidirektionale Vertrauensstellung verwendet werden soll.

Folgen Sie dann der Anleitung zum Einrichten der Vertrauensstellung zwischen der lokalen AD-Domain und der Managed Microsoft AD-Domain.

Windows-VM einrichten und Windows-Anmeldung erstellen

Nachdem Sie die Vertrauensstellung zwischen der lokalen AD-Domain und der Managed Microsoft AD-Domain eingerichtet haben, führen Sie folgende Schritte aus: Für Beispielzwecke wird in den folgenden Schritten SQL Server Management Studio (SSMS) verwendet, das auf einer Windows-VM ausgeführt wird, die in der VPC Ihres Google Cloud-Projekts gehostet wird:

1. Erstellen Sie eine Windows-VM.
   • Erstellen Sie eine VM mit einer Version von Windows, die von Managed Microsoft AD unterstützt wird.
   • Erstellen Sie die VM in dem Projekt, in dem Ihre Managed Microsoft AD-Domain gehostet wird. Wenn es eine freigegebene VPC gibt, die ein autorisiertes Netzwerk ist, können Sie die VM auch in einem ihrer Dienstprojekte erstellen.
   • Erstellen Sie die VM in einem VPC-Netzwerk, das ein autorisiertes Netzwerk der Managed Microsoft AD-Domain ist und den Zugriff auf private Dienste für Cloud SQL konfiguriert hat.
2. Verbinden Sie die Windows-VM mit der Managed Microsoft AD-Domain.
3. Installieren Sie SSMS auf der Windows-VM.
4. Lösen Sie die lokale Domain im VPC-Netzwerk auf.
   • Aktivieren Sie im autorisierten Netzwerk, in dem die Windows-VM ausgeführt wird, die lokale DNS-Auflösung. Führen Sie dazu die Schritte auf der Seite Abfragen für nicht verwaltete Microsoft AD-Objekte auflösen aus. Die Schritte auf dieser Seite sind erforderlich, damit die Kerberos-basierte Windows-Authentifizierung für lokale Nutzer angewendet werden kann.

5. Erstellen Sie eine Windows-Anmeldung für einen lokalen Nutzer.

   • Folgen Sie der Anleitung ANMELDUNG ERSTELLEN, um eine Windows-Anmeldung für einen lokalen Nutzer zu erstellen. Führen Sie beispielsweise einen Befehl wie diesen aus:

   CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS
   

6. Melden Sie sich mithilfe der anwendungsspezifischen Anleitung zur Anmeldung bei einem lokalen Nutzer bei Ihrer Cloud SQL for SQL Server-Instanz an. Wenn Sie beispielsweise SQL Server Management Studio verwenden, folgen Sie dieser Anleitung.

Probleme im Zusammenhang mit einem lokalen AD-Nutzer beheben

Wenn während der Anmeldung bei einer Cloud SQL for SQL Server-Instanz ein Problem auftritt, prüfen Sie Folgendes:

• Prüfen Sie die Firewallkonfiguration des lokalen Netzwerks und der projektautorisierten VPC mithilfe der Anleitung unter Vertrauensstellung mit einer lokalen Domain erstellen.
• Prüfen Sie das Namenssuffixrouting für die lokale Vertrauensstellung.
• Prüfen Sie, ob Sie die folgenden DNS-Auflösungsvorgänge über die Windows-VM ausführen können, auf der SSMS ausgeführt wird:
  • nslookup fqdn-for-managed-ad-domain
  • nslookup fqdn-for-on-premises-ad-domain
  • nslookup fqdn-for-cloud-sql-server-instance

Tipps

• Instanzen mit öffentlichen IP-Adressen werden unterstützt, sofern sie auch private IP-Adressen haben. Private IP-Adressen müssen für die Instanz aktiviert sein. Sie können dann über eine öffentliche IP-Adresse oder eine private IP-Adresse eine Verbindung zur Instanz herstellen, sofern beide verfügbar sind.
• Prüfen Sie vor der Erstellung einer Instanz, auch als Ersatzinstanz, bei Bedarf die folgenden Punkte:
  • Informationen zur Verwendung privater IP-Adressen
  • Öffentliche IP-Adresse konfigurieren
• Terraform wird unterstützt.
• Wenn einer der folgenden Fehler angezeigt wird, prüfen Sie, ob Sie alle Voraussetzungen für die Einbindung erfüllt haben:
  • "Dienstkonto pro Produkt und Projekt wurde nicht gefunden"
  • "Unzureichende Berechtigung für die Einbindung in Managed Service for Microsoft Active Directory-Domain"
• Wenn Sie den Fehler "Domain nicht gefunden" erhalten, prüfen Sie, ob die Groß- und Kleinschreibung beachtet wurde.
• Wenn die Windows-Authentifizierung bei einer Domain fehlschlägt, die über eine Vertrauensstellung verbunden ist, prüfen Sie, ob die Windows-Authentifizierung für einen Nutzer aus einer verwalteten Domain möglich ist. Falls ja, gehen Sie so vor:
  1. Prüfen Sie, ob Sie einen DNS-Namen verwendet haben. IP-Adressen werden von Domains, die über eine Vertrauensstellung verbunden sind, nicht unterstützt.
  2. Achten Sie darauf, dass alle Schritte zum Erstellen einer Vertrauensstellung mit einer lokalen Domain ausgeführt wurden, einschließlich das Öffnen aller Firewallports.
  3. Prüfen Sie die Vertrauensstellung.
  4. Prüfen Sie, ob die Richtung der Vertrauensstellung Nutzern aus der Domain (über eine Vertrauensstellung verbunden) die Authentifizierung in der verwalteten Domain ermöglicht.
  5. Prüfen Sie, ob das Namenssuffixrouting für die Domain festgelegt ist, die über eine Vertrauensstellung verbunden ist.
  6. Prüfen Sie, ob die Vertrauensstellung funktioniert, ohne Cloud SQL for SQL Server zu verwenden:
     1. Erstellen Sie eine Windows-VM.
     2. Verknüpfen Sie die Domain mit der Managed Microsoft AD-Domain.
     3. Versuchen Sie beispielsweise, Notepad als Nutzer aus der Domain auszuführen, die über eine Vertrauensstellung verbunden ist.
  7. Starten Sie die Client-VM neu und testen Sie die Windows-Authentifizierung noch einmal.
• Sie können versuchen, eine SQL Server-Anmeldung zu erstellen, erhalten dann aber die folgende Fehlermeldung: "Windows NT user or group domain\name not found. Check the name again". Das kann daran liegen, dass lokale Domaingruppen nicht unterstützt werden. Verwenden Sie gegebenenfalls globale oder universelle Gruppen.
• Bei der Ausführung durch einen Nutzer aus einer Domain, die über eine Vertrauensstellung verbunden ist, wird bei SQL Server-Abfragen eventuell die folgende Fehlermeldung ausgegeben: "Could not get information about Windows NT group/user". Dieser Fehler kann beispielsweise auftreten, wenn Sie Anmeldungen über Domains erstellen, die über eine Vertrauensstellung verbunden sind. Dieser Fehler kann auch vorkommen, wenn Sie Berechtigungen für das Anmelden von Domains gewähren, die über eine Vertrauensstellung verbunden sind. In diesen Fällen führt das Wiederholen des Vorgangs oft zum Erfolg. Wenn der nochmalige Versuch fehlschlägt, schließen Sie die Verbindung und öffnen Sie eine neue Verbindung.

• Wenn Sie die Fehlermeldung „Konnte keine Informationen über Windows NT-Gruppe/Nutzer erhalten“ sehen, prüfen Sie die Netzwerkkonnektivität zu lokalen Domains mit der Logdatei active_directory.log, die in Cloud Logging für die Cloud SQL for SQL Server-Instanz verfügbar ist. Diese Datei enthält die folgenden Diagnosen zu Konnektivitätsänderungen an der lokalen Domain:

  • Vertrauenswürdige lokale Domains der Cloud SQL for SQL Server-Instanz. Das folgende Log zeigt zum Beispiel den Wechsel von keinen vertrauenswürdigen Domains zu zwei neuen vertrauenswürdigen Domains mit den NetBIOS-Namen ONPREM und CHILD:

    2023-06-12 20:55:09.975 Detected change in trusted onprem domains: Previously trusted onprem domains: []. Current trusted onprem domains: [ONPREM CHILD]

    Wenn eine lokale Domain nicht aufgelistet ist oder als nicht vertrauenswürdig protokolliert ist, prüfen Sie, ob die Vertrauensstellung mit der verwalteten AD-Domain besteht und validiert ist. Wenn eine einseitige Vertrauensstellung zwischen der verwalteten AD-Domain und der lokalen Domain besteht, sind andere lokale Domains, denen die lokale Domain vertraut, möglicherweise nicht sichtbar.
  • Erreichbare und nicht erreichbare lokale Domains mit einem regulären Ping von der Cloud SQL for SQL Server-Instanz. Das folgende Log zeigt zum Beispiel den Wechsel von keinen erreichbaren Domains zu zwei neuen erreichbaren Domains, onprem.com und child.onprem.com:

    2023-06-12 20:55:10.664 Detected change in reachable onprem domains: Previously reachable onprem domains: []. Current reachable onprem domains: [onprem.com child.onprem.com]

    Wenn eine Domain nicht in den Erreichbarkeitsprotokollen aufgeführt ist, muss sie zuerst als vertrauenswürdige Domain protokolliert werden. Andernfalls wird die Erreichbarkeit nicht geprüft. Es gibt immer ein VPC-Peering zwischen einem Projekt mit lokalen Instanzen und Google Cloud-Projekten. Selbst ein weiteres VPC-Peering führt zu transitiven Peering-Verbindungen, die Cloud SQL nicht unterstützt. Stattdessen empfehlen wir, einen VPN-Tunnel zu verwenden, um eine lokale Domain mit Cloud SQL zu verbinden. Es sollte maximal eine Peering-Verbindung zwischen dem lokalen Projekt und dem Google Cloud-Projekt mit den Cloud SQL for SQL Server-Instanzen geben.
  • Erfolgreiche und fehlgeschlagene Pings vom Remoteprozeduraufruf (Microsoft Remote Procedure Call, MSRPC) zu lokalen Domains von der Cloud SQL for SQL Server-Instanz. Das folgende Log zeigt zum Beispiel den Wechsel von keinen pingfähigen MSRPC-Domains zu zwei neuen pingfähigen MSRPC-Domains: ONPREM und CHILD.

    2023-06-12 20:55:10.664 Detected change in MSRPC pingable domains: Previously pingable onprem domains: []. Current pingable onprem domains: [ONPREM CHILD]

    MSRPC-Pings sind als zusätzliche Diagnosen enthalten und funktionieren möglicherweise bei einigen Konfigurationen nicht. Sie können die Verbindung zur lokalen Domain weiterhin mit den ersten beiden Diagnosen prüfen.

• Wenn SQL Server-Abfragen die Fehlermeldung ausgeben "The login is from an untrusted domain" werden IP-Adressen für Nutzer aus Domains, die über eine Vertrauensstellung verbunden sind, nicht unterstützt. Darüber hinaus lässt sich das Problem möglicherweise durch folgende Aktionen beheben:

  • Wenn Sie Nutzer über eine IP-Adresse aus einer verwalteten Domain verbinden möchten, folgen Sie dieser Anleitung.
  • Vermeiden Sie die Verwendung von Proxys und verwenden Sie immer den gleichen DNS-Namen, um eine Verbindung zu Cloud SQL for SQL Server herzustellen, so wie er in der Google Cloud Console angezeigt wird.
  • Löschen Sie die vorhandenen Kerberos-Tickets. Der obige Fehler kann auftreten, wenn ein Client vorhanden ist, der kürzlich mit einer Cloud SQL for SQL Server-Instanz verbunden war, und die Instanz beendet und gestartet wurde. Dieser Fehler kann auch vorkommen, wenn die Windows-Authentifizierung deaktiviert war und dann für die Cloud SQL for SQL Server-Instanz wieder aktiviert wurde. Wenn der Client den Cache für Windows-Anmeldedaten verwendet, sperren und entsperren Sie die Client-Workstation oder führen Sie klist purge aus.

• Bei dem Versuch, die Windows-Authentifizierung zu aktivieren, wird möglicherweise der folgende Fehler angezeigt: "Diese Instanz benötigt ein aktuelleres Erstellungsdatum, um den verwalteten Dienst für Microsoft Active Directory zu unterstützen." Beachten Sie bei diesem Fehler Folgendes:

  • Wenn in Cloud SQL eine Cloud SQL for SQL Server-Instanz am oder vor dem 12. März 2021 erstellt wurde, kann sie nicht in Managed Microsoft AD eingebunden werden.
  • In bestimmten Fällen kann dieser Fehler auftreten, wenn Sie eine Cloud SQL for SQL Server-Instanz erstellen und Managed Microsoft AD beim Erstellen nicht aktivieren. Nachdem Sie sich die anderen Tipps in diesem Abschnitt angesehen haben, erstellen Sie eine neue Instanz und aktivieren Managed Microsoft AD beim Erstellen der Instanz.

• Der Versuch, eine Cloud SQL for SQL Server-Instanz zu erstellen, führt möglicherweise zu folgendem Fehler: „This instance does not support Managed Service for Microsoft Active Directory.“ Wenn Sie diese Fehlermeldung erhalten, wird das Projekt möglicherweise nicht unterstützt. Versuchen Sie es dann mit einem anderen Projekt.

• Wenn eine Instanz fortlaufend Probleme mit der Windows-Authentifizierung aufweist (unabhängig davon, ob die Instanz kürzlich aktualisiert wurde), heben Sie die Verknüpfung zur Managed Active Directory-Domain auf und stellen sie dann wieder her. Verwenden Sie dazu das Aktualisierungsverfahren, um die Verknüpfung mit der Domain aufzuheben und dann wiederherzustellen. Dadurch werden keine vorhandenen Windows-authentifizierten Nutzer oder Anmeldungen in Ihren Datenbanken entfernt. Allerdings führt das Entfernen der Windows-Authentifizierung zum Neustart einer Instanz.

• Verwenden Sie das AD-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.

Fehlerbehebung

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Nächste Schritte

• Lesen Sie sorgfältig die Übersichtsseite. Dort erhalten Sie Informationen zu Beschränkungen und zu nicht unterstützten Funktionen. Auf dieser Seite finden Sie auch Links zu zusätzlichen Dokumenten.