Active Directory-Diagnosetool für Cloud SQL

Das Active Directory (AD)-Diagnosetool ist ein PowerShell-Skript, mit dem Sie Probleme bei der AD-Einrichtung mit Ihrer lokalen Domain und Cloud SQL for SQL Server-Instanzen in beheben können. Google Cloud

Das Tool führt verschiedene Prüfungen auf Probleme durch, z.0B. geschlossene Ports, FQDN-Suchvorgänge und DNS-Probleme. Es wird auf einer lokalen Windows-VM ausgeführt, die einer der Domaincontroller für Ihre lokale Domain ist.

Auf dieser Seite wird beschrieben, wie Sie das Active Directory-Diagnosetool für Cloud SQL verwenden, und die Prüfungen erläutert, die das Tool durchführt.

Vorbereitung

Achten Sie darauf, dass die folgenden Komponenten eingerichtet sind, bevor Sie das AD-Diagnosetool verwenden:

  • Eine AD-aktivierte lokale Domain.
  • Eine Managed AD-Domain in der Google Cloud Console.
  • Eine Cloud SQL for SQL Server-Instanz, die mit der Managed AD-Domain verbunden ist.

AD-Diagnosetool verwenden

So verwenden Sie das AD-Diagnosetool:

  1. Melden Sie sich bei einem der lokalen Domaincontroller oder einer VM an, die mit der lokalen Domain verbunden ist.
  2. Laden Sie das Skript diagnose_ad.ps1 auf die VM herunter.
  3. Starten Sie PowerShell als Administrator.

  4. Führen Sie das Skript diagnose_ad.ps1 im PowerShell-Fenster mit dem folgenden Befehl aus.

    powershell -command "& { . C:\\<var>SCRIPT_PATH</var>\\diagnose_ad.ps1; Run-Tool }"

  5. Geben Sie die folgenden Informationen ein, wenn Sie dazu aufgefordert werden:

    • Lokaler Domainname, z. B. my-onprem-domain.com
    • Managed AD-Domainname, z. B. my-ad-domain.com
    • Liste der voll qualifizierten Domainnamen (FQDNs) und privaten IP-Adressen von SQL Server. Diese Liste ist in der Google Cloud Console auf der Seite Übersicht der Instanz verfügbar.

Das Tool führt dann eine Reihe von Prüfungen durch, wie unter Vom AD-Diagnosetool durchgeführte Prüfungen beschrieben.

Vom AD-Diagnosetool durchgeführte Prüfungen

HäkchenBeschreibung Hinweise und Empfehlungen
Verfügbare Domaincontroller Sendet einen Ping an die IP-Adresse jedes Domaincontrollers in der lokalen Domain, um sicherzustellen, dass sie erreichbar sind. Die verbleibenden Prüfungen werden mit den erreichbaren IP-Adressen fortgesetzt. Wenn diese Prüfung fehlschlägt, stellen Sie die Netzwerkverbindung zu den verbleibenden lokalen Domaincontrollern her. Weitere Informationen finden Sie unter Netzwerkinfrastruktur erstellen.
Ports Prüft, ob alle erforderlichen TCP- und UDP-Ports für AD auf allen den lokalen Domaincontrollern geöffnet sind. Diese Prüfung gibt für den RPC-Portbereich (49152–65535) einen Warnstatus zurück, da keine konsistente Liste offener Ports vorhanden ist. Wir empfehlen, zu prüfen, ob eine Firewallregel zum Zulassen dieses Bereichs festgelegt ist. Weitere Informationen finden Sie unter Firewallports öffnen
DNS-Server Prüft auf eine fehlerfreie und fehlertolerante AD-Einrichtung. Diese Prüfung gibt eine Warnung zurück, wenn das Skript nicht auf einem lokalen Domaincontroller ausgeführt wird. Wir empfehlen, AD so einzurichten, dass es fehlertolerant ist, indem Sie primäre und sekundäre DNS-Server festlegen.
FQDN (Managed AD-Domain) Führt einen nslookup für den von Ihnen angegebenen Managed AD-Domainnamen aus. Bei dieser Prüfung wird geprüft, ob die Managed AD-Domain über den lokalen Domaincontroller erreichbar ist. Wenn die Prüfung fehlschlägt, versuchen Sie, eine Netzwerkverbindung zwischen Ihrem lokalen Netzwerk und Ihrer Virtual Private Cloud (VPC) von Google Cloud herzustellen. Weitere Informationen finden Sie unter Netzwerkverbindung herstellen.
FQDN (SQL Server) Führt einen nslookup für die von Ihnen angegebenen SQL Server-FQDNs aus. Mit dieser Prüfung wird geprüft, ob Ihre Instanz über den lokalen Domaincontroller erreichbar ist. Wenn die Prüfung fehlschlägt, versuchen Sie, eine Netzwerkverbindung zwischen Ihrem lokalen Netzwerk und Ihrer Virtual Private Cloud (VPC) von Google Cloud herzustellen. Weitere Informationen finden Sie unter Netzwerkverbindung herstellen.
DC-Replikation Sucht nach AD-Replikationsfehlern zwischen den lokalen Domaincontrollern. Wenn das Skript auf einer lokalen Domain ausgeführt wird, die einer VM beitritt, schlägt der Status „Fehlgeschlagen“ fehl, wenn Powershell nicht als Active Directory-Domainnutzer ausgeführt wird. Wenn diese Prüfung fehlschlägt, führen Sie die Schritte unter Installation testen aus.
DNS-Weiterleitung Es wird nach einer Konfiguration für die bedingte DNS-Weiterleitung auf den lokalen Domaincontrollern gesucht, die erforderlich ist, um Anfragen von lokalen Domaincontrollern an Managed AD-Domaincontroller weiterzuleiten. Diese Prüfung kann fehlschlagen, wenn das Skript nicht auf einem lokalen Domaincontroller ausgeführt wird. Wir empfehlen das Konfigurieren bedingter DNS-Forwarder.
Trust-Einrichtung Prüft, ob die AD-Vertrauensstellung zwischen der lokalen Domain und der Managed AD-Domain eingerichtet ist. Bei dieser Prüfung wird überprüft, ob die AD-Vertrauensstellung zwischen der lokalen und der Managed AD-Domain eingerichtet ist. Wir empfehlen, eine Vertrauensstellung zwischen Ihrer lokalen Domain und Ihrer Managed Microsoft AD-Domain zu erstellen. Weitere Informationen finden Sie unter Vertrauensstellung einrichten
Lokale Sicherheitsrichtlinie Prüft, ob die Konfiguration der lokalen Sicherheitsrichtlinie Network access: Named pipes that can be accessed anonymously festgelegt wurde. Diese Prüfung ist erforderlich, um eine AD-Vertrauensstellung zu erstellen. Diese Prüfung wird wahrscheinlich fehlschlagen, wenn das Skript nicht auf einem lokalen Domaincontroller ausgeführt wird. Für diese Prüfung müssen Sie PowerShell als Administrator ausführen, um die Einstellungen der lokalen Sicherheitsrichtlinie zu prüfen. Wenn die Prüfung fehlschlägt, empfehlen wir, die lokale Sicherheitsrichtlinie für Ihre lokale Domain zu prüfen .
Namenssuffixrouting Prüft, ob das Namenssuffixrouting zur Managed AD-Domain auf dem lokalen Domaincontroller aktiviert ist. Diese Prüfung ist erforderlich, um Anfragen von einer lokalen Gesamtstruktur an eine Managed AD-Gesamtstruktur weiterzuleiten. Für diese Prüfung müssen Sie PowerShell als Administrator ausführen, um die Einstellungen für das Namenssuffix Routing zu prüfen. Im Falle eines Fehlers empfehlen wir, das Namenssuffixrouting für die lokale Vertrauensstellung zu aktualisieren.
Kerberos-Ticket für die lokale Domain Prüft, ob die Kerberos-Authentifizierung in der lokalen Domain aktiviert ist. Es wird nach einem vorhandenen Kerberos-Ticket für die lokale Domain gesucht. Wenn es nicht gefunden wird, wird versucht, ein neues Ticket zu generieren. Bei dieser Prüfung wird versucht, ein vorhandenes Kerberos-Ticket für den lokalen DC zu finden. Wenn das nicht gelingt, wird versucht, ein neues Ticket als Bestätigung zu generieren. Fehler bei anderen Prüfungen können zu einem Fehler bei dieser Prüfung führen. Wenn Sie Fehler bei anderen Prüfungen beheben, sollte auch ein Fehler für diese Prüfung behoben werden.
Kerberos-Ticket für SQL Server Prüft, ob die Kerberos-Authentifizierung in der lokalen Domain aktiviert ist. Es wird nach einem vorhandenen Kerberos-Ticket für jeden von Ihnen angegebenen Namen eines SQL-Server-Diensthauptkontos (SPN, Service Principal Name) gesucht. Der SPN für SQL Server ist MSSQLSvc/{SQL Server FQDN}:1433. Wenn das Abrufen eines Tickets für den SPN fehlschlägt, prüft Cloud SQL, ob der Windows-Registry-Wert für das Zulassen von IP-Adressen in Hostnamen festgelegt ist. Wenn er festgelegt ist, versuchen Sie, ein Ticket mit dem SPN MSSQLSvc/{SQL Server IP}:1433 abzurufen.Weitere Informationen zu
finden Sie in der Microsoft-Dokumentation. 		Bei dieser Prüfung wird versucht, ein vorhandenes Kerberos-Ticket für SQL Server zu finden. Wenn das nicht gelingt, wird versucht, ein neues Ticket als Bestätigung zu generieren. Fehler bei anderen Prüfungen können zu einem Fehler bei dieser Prüfung führen. Wenn Sie Fehler bei anderen Prüfungen beheben, sollte auch ein Fehler für diese Prüfung behoben werden.

Weitere Informationen