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.

Hinweis

  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. Sie müssen das Cloud SDK installieren und initialisieren.
  4. Sie müssen die Rolle "Cloud SQL-Administrator" in Ihrem Nutzerkonto haben. Zur IAM-Seite.
  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.

Console

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

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

REST

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.

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

Wenn eine Instanz bereits mit einer verwalteten Active Directory-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.

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 entsprechende Übersicht zu öffnen.
  3. Klicken Sie auf Bearbeiten.
  4. Klicken Sie auf Authentifizierung. Im Drop-down-Menü Einer Active Directory-Domain beitreten werden alle Managed 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"
      }
   }
}

Windows-Authentifizierung von einer Instanz entfernen

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

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 entsprechende Übersicht 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 Kerberos-Clients so konfiguriert sein, dass sie IP-Hostnamen unterstützen. Bei Domains, die über eine Vertrauensstellung verbunden sind, wird die Anmeldung über eine IP-Adresse nicht unterstützt.

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:

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 muss der Cloud SQL Auth-Proxy auf Port 1433 ausgeführt werden. Sie ordnen 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_x64.exe -credential_file credential.json  -instances=project:name=tcp:1433

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 bei NTLM-Fallback in Clients

Wenn Sie die Windows-Authentifizierung und eine Instanz-IP-Adresse verwenden, um sich bei einer Instanz anzumelden, muss ein Kerberos-Client für die Unterstützung von IP-Hostnamen konfiguriert sein.

Die NTLM-Authentifizierung wird nicht unterstützt. 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 der obige Fehler durch einen Fallback auf NTLM verursacht wird:

  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, wurde der Fehler wahrscheinlich durch einen NTLM-Fallback verursacht.
  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 der obige Fehler durch einen NTML-Fallback verursacht wird. 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 hier 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 FQDNs oder IP-Adressen, die von der Google Cloud Console abgerufen wurden, um eine Verbindung 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 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.

Wenn während der Anmeldung bei einer 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.
  • 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 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 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 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." Wichtige Hinweise:
    • Wenn in Cloud SQL eine SQL Server-Instanz am oder vor dem 12. März 2021 erstellt wurde, kann sie nicht in Managed Microsoft AD eingebunden werden.
  • Der Versuch, eine 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.

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. Achten Sie darauf, dass der Domainname korrekt und im selben Nutzerprojekt vorhanden 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 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.