Managed Microsoft AD mit Cloud SQL verwenden

MySQL   |  PostgreSQL   |  SQL Server

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.

Hinweis: Prüfen Sie vor der Einbindung die Übersicht über Managed Microsoft AD in Cloud SQL. Dazu gehört Folgendes: Einschränkungen und Alternativen.

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

Hinweis: Wenn Sie in eine verwaltete AD-Domain in einem anderen Projekt einbinden, lesen Sie zuerst die Verfahren und Einschränkungen.

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.

Hinweis: In seltenen Fällen kann die Instanzerstellung mit der Windows-Authentifizierung bis zu 30 Minuten dauern.

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.

Hinweis: Nachdem Sie eine Instanz mit Windows-Authentifizierung erstellt haben, wird eine zusätzliche Anmeldung in Cloud SQL for SQL Server erstellt. Die Anmeldung hat das Format [domain]\sql_[letters-and-digits]. Cloud SQL könnte beispielsweise eine Anmeldung mit dem Namen AD\sql_1a1a6145bc1aaaa erstellen. Die Anmeldung befindet sich in der Managed AD-Domain. Sie können die Anmeldung ignorieren. Sie können sie nicht entfernen. Wenn Sie jedoch die Windows-Authentifizierung für die Instanz deaktivieren, wird die Anmeldung automatisch gelöscht.

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

Console

Hinweis: Bevor Sie mit den folgenden Schritten beginnen, lesen Sie die Voraussetzungen für die Einbindung. Beachten Sie außerdem die Verfahren und Einschränkungen für die Einbindung in einer verwalteten AD-Domain in einem anderen Projekt.

1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

   Cloud SQL-Instanzen aufrufen

2. Klicken Sie auf Instanz erstellen.
3. Klicken Sie auf Choose SQL Server.
4. Einen Namen für die Instanz eingeben. Der Instanzname sollte keine vertraulichen Informationen oder personenbezogenen Daten enthalten, da er extern sichtbar ist. Die Projekt-ID muss im Instanznamen nicht angegeben werden. Sie wird bei Bedarf automatisch erstellt, beispielsweise in den Logdateien.
5. Geben Sie das Passwort für den Nutzer 'sqlserver' ein.
6. Legen Sie die Region für die Instanz fest. Best Practices für die Einbindung in Managed Microsoft AD
7. Legen Sie im Bereich Konfigurationsoptionen die gewünschten Optionen fest. Warten Sie aber im nächsten Schritt auf die Authentifizierungsoptionen.
8. Klicken Sie auf Authentifizierung. Im Drop-down-Menü zum Verknüpfen mit einer verwalteten Active Directory-Domain sind alle Managed Microsoft AD-Domains aufgeführt, die Ihrem Projekt zuvor hinzugefügt wurden.
9. Wählen Sie aus dem Drop-down-Menü zum Verknüpfen mit einer verwalteten Active Directory-Domain eine Domain aus.
10. Klicken Sie nach der Auswahl der Konfigurationsoptionen auf Erstellen. Cloud SQL erstellt automatisch ein produkt- und ein projektspezifisches Dienstkonto für Sie. Wenn das Konto nicht die erforderliche Rolle hat, werden Sie aufgefordert, die Rolle managedidentities.sqlintegrator zuzuweisen.

gcloud

Hinweis: Bevor Sie mit den folgenden Schritten beginnen, lesen Sie die Voraussetzungen für die Einbindung. Beachten Sie außerdem die Verfahren und Einschränkungen für die Einbindung in einer verwalteten AD-Domain in einem anderen Projekt.

Mit dem folgenden Befehl wird eine Instanz erstellt, die in Managed Microsoft AD eingebunden und daher für die Windows-Authentifizierung aktiviert ist. Informationen zum grundlegenden Befehl für das Erstellen einer Instanz finden Sie unter Instanzen erstellen.

Geben Sie den Parameter --active-directory-domain=DOMAIN im Befehl gcloud an. Geben Sie beispielsweise Folgendes an: --active-directory-domain=ad.mydomain.com.

Im Folgenden ist ein Prototyp des Befehls gcloud dargestellt:

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

Terraform

Verwenden Sie eine Terraform-Ressource, um eine Instanz zu erstellen, die in Managed Microsoft AD eingebunden ist.

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
}

REST

Hinweis: Bevor Sie mit den folgenden Schritten beginnen, lesen Sie die Voraussetzungen für die Einbindung. Beachten Sie außerdem die Verfahren und Einschränkungen für die Einbindung in einer verwalteten AD-Domain in einem anderen Projekt.

Mit der REST API können Sie eine Instanz erstellen, die in Managed Microsoft AD eingebunden ist. Legen Sie für das Feld domain eine Domain wie z. B. subdomain.mydomain.com fest, wie in diesem Prototyp einer Anfrage dargestellt:

{
   "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.

Achtung: Das Entfernen der Windows-Authentifizierung führt zum Neustart einer Instanz.

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

Hinweis: Bevor Sie mit den Schritten in diesem Abschnitt beginnen, lesen Sie die Voraussetzungen für die Einbindung und die Best Practices.

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.

Hinweis: 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.

Console

1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

   Cloud SQL-Instanzen aufrufen

2. Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
3. Klicken Sie auf Bearbeiten.
4. Klicken Sie auf Authentifizierung. Im Drop-down-Menü Ein Active Directory-Domain beitreten werden alle verwalteten Microsoft AD-Domains aufgelistet, die zuvor in Ihrem Projekt hinzugefügt wurden.
5. Wählen Sie aus dem Drop-down-Menü zum Verknüpfen mit einer verwalteten Active Directory-Domain eine neue (Ersatz-)Domain für Ihre Instanz aus.
6. Klicken Sie auf Speichern, um die Änderungen zu übernehmen.

gcloud

Im Folgenden ist der Prototyp eines Befehls zum Aktualisieren einer vorhandenen Instanz dargestellt. Mit diesem Befehl wird eine Domain oder ersetzt. Übergeben Sie so --active-directory-domain=DOMAIN an den Befehl:

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

REST

Mit der REST API können Sie eine vorhandene Instanz aktualisieren. Legen Sie für das Feld domain eine Domain wie z. B. subdomain.mydomain.com fest: Im Folgenden ist der Prototyp einer Anfrage aufgeführt:

{
   "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.

Hinweis: Für die Integration in eine AD-Domain in einem anderen Projekt sind gcloud-Befehle oder die Cloud SQL REST API erforderlich. Derzeit können Sie die Google Cloud Console nicht für diesen Zweck verwenden.

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.

Achtung: Das Entfernen der Windows-Authentifizierung führt zum Neustart einer Instanz.

Console

1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

   Cloud SQL-Instanzen aufrufen

2. Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
3. Klicken Sie auf Bearbeiten.
4. Klicken Sie auf Authentifizierung. Im Drop-down-Menü zum Verknüpfen mit einer verwalteten Active Directory-Domain sind alle Managed Microsoft AD-Domains aufgeführt, die Ihrem Projekt hinzugefügt wurden.
5. Wählen Sie im Drop-down-Menü für Ihre Instanz Keine Domain/Später hinzufügen aus.
6. Lesen Sie die Meldung zum Neustart einer Instanz und klicken Sie auf Schließen.
7. Klicken Sie auf Speichern, um die Änderungen zu übernehmen.

gcloud

Um eine Instanz aus einer Domain und damit die Windows-Authentifizierung zu entfernen, verwenden Sie einen leeren Wert für die Domain. Geben Sie dazu im Befehl für den Parameter --active-directory-domain nichts an, wie im Folgenden dargestellt:

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

REST

Mit der REST API können Sie eine Instanz aus einer Domain entfernen. Geben Sie in das Feld domain einen leeren Wert ein:

{
   "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 konfigurieren, um IP-Hostnamen zu unterstützen. Cloud SQL unterstützt keine Anmeldungen von Domains, die über eine Vertrauensstellung verbunden sind.

Hinweis: Cloud SQL unterstützt diese Verbindungsfunktion nicht von Domains, die über eine Vertrauensstellung verbunden sind. Informationen zu solchen Domains finden Sie unter Lokale AD-Nutzer: Windows-Anmeldung erstellen.

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 einen vordefinierten Service Principal Name (SPN)-Eintrag einer Cloud SQL Auth-Proxy-Adresse 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 so konfigurieren, dass IP-Hostnamen unterstützt werden.

Cloud SQL unterstützt keine NTLM-Authentifizierung. Es kann jedoch vorkommen, dass einige Kerberos-Clients darauf zurückgreifen. 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 überprü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 die NTLM-Fallback wahrscheinlich 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 Sie FQDNS verwenden 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 FQDNs oder IP-Adressen, die Sie von der Google Cloud Console erhalten haben, um eine Verbindung zur Windows-Authentifizierung herzustellen.

Lokale AD-Nutzer: Windows-Anmeldung erstellen

Hinweis: Es wird nicht empfohlen, einen lokalen AD-Nutzer zum Erstellen einer Windows-Anmeldung zu verwenden. Verwenden Sie stattdessen einen Managed AD-Nutzer oder ein sqlserver-Konto in Cloud SQL.

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.

Hinweis: Es wird dringend empfohlen, eine bidirektionale Vertrauensstellung zwischen einer verwalteten AD-Domain und einer lokalen Domain zu verwenden, da es bei Instanzen mit einseitiger Vertrauensstellung zu lang andauernden Verbindungsabbrüchen kommen kann und bestimmte privilegierte Vorgänge wie das Erstellen und Löschen von Anmeldungen nicht ausgeführt werden können. Weitere Informationen finden Sie unter Informationen zur Active Directory-Authentifizierung für SQL Server unter Linux und Containern.

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

Hinweis: Lesen Sie zusätzlich zu den Tipps in diesem Abschnitt die Informationen unter Einschränkungen und Alternativen.

• 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:

  Hinweis: Die Zeitstempel in der Datei sind in der Ortszeit angegeben.
  • Vertrauenswürdige lokale Domains von der Cloud SQL for SQL Server-Instanz. Das folgende Log zeigt beispielsweise die Änderung von keinen vertrauenswürdigen Domains zu zwei neuen vertrauenswürdigen Domains als 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 wird, 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 sind über einen regulären Ping von der Cloud SQL for SQL Server-Instanz erreichbar. 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 Erreichbarkeitslogs aufgeführt ist, muss sie zuerst als vertrauenswürdige Domain protokolliert werden. Andernfalls wird sie nicht auf Erreichbarkeit geprüft. Wir haben 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. Wir empfehlen stattdessen, einen VPN-Tunnel für die Verbindung einer lokalen Domain mit Cloud SQL zu verwenden. Es sollte höchstens eine Peering-Verbindung zwischen dem lokalen Projekt und dem Google Cloud-Projekt mit den Cloud SQL for SQL Server-Instanzen vorhanden sein.
  • 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 nicht bei einigen Konfigurationen. Sie können die lokale Domainverbindung über die ersten beiden Diagnosen weiterhin 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:

Fehler	Das könnte das Problem sein	Lösungsvorschlag
Per-product, per-project service account not found.	Der Name des Dienstkontos ist falsch.	Prüfen Sie auf der Seite "Dienstkonten", ob ein Dienstkonto für das richtige Nutzerprojekt vorhanden ist.
Insufficient permission to integrate with Managed Service for Microsoft Active Directory domain.	Die Rolle managedidentities.sqlintegrator fehlt im Dienstkonto.	Fügen Sie auf der Seite "IAM und Verwaltung" die Rolle managedidentities.sqlintegrator zu Ihrem Dienstkonto hinzu.
Domain not found.	Die Domain ist nicht vorhanden oder wurde falsch eingegeben.	Prüfen Sie, ob der Domainname korrekt ist. Die Groß- und Kleinschreibung wird berücksichtigt.
The domain is busy with another operation. Please retry.	Eine andere Cloud SQL-Instanz führt einen Vorgang in derselben Managed Active Directory-Domain aus.	Wiederholen Sie den Vorgang. Wenn Sie mehrere Aktualisierungen von Cloud SQL-Instanzen ausführen, die mit derselben Domain verbunden sind, beschränken Sie die Anzahl der parallel ausgeführten Vorgänge.
The operation completed but an update to Active Directory failed. You may experience issues with Windows Authentication on this instance, please see https://cloud.google.com/sql/docs/sqlserver/configure-ad for tips.	Die erforderlichen Aktualisierungen konnten nicht auf der Managed Active Directory-Domain ausgeführt werden.	Wenn Probleme mit der Windows-Authentifizierung auftreten, können Sie versuchen, die Verknüpfung der verwalteten Active Directory-Domain aufzuheben und dann wieder herzustellen. 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.
This instance would need a more recent creation date to support Managed Service for Microsoft Active Directory.	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.	Führen Sie den Vorgang auf einer Instanz aus, die nach dem 12. März 2021 erstellt wurde.

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.