שימוש בשירות מנוהל ל-Microsoft AD עם Cloud SQL

בדף הזה מוסבר איך להשתמש ב-Cloud SQL כדי:

  • שילוב עם שירות מנוהל ל-Microsoft Active Directory (שנקרא גם שירות מנוהל ל-Microsoft AD).
  • התחברות למכונה באמצעות משתמש AD.

מכונת Cloud SQL שמשולבת עם שירות מנוהל ל-Microsoft AD תומכת באימות Windows בנוסף לאימות SQL.

לפני שמתחילים

  1. במסוף Google Cloud , בוחרים את שם הפרויקט.
  2. מוודאים שהחיוב מופעל בפרויקט Google Cloud . איך מוודאים שהחיוב מופעל בפרויקט
  3. מתקינים ומפעילים את ה-CLI של gcloud.
  4. מוודאים שיש לכם את התפקיד Cloud SQL Admin בחשבון המשתמש. כניסה לדף IAM
  5. דרישות מוקדמות לשילוב

יצירת מכונה וירטואלית עם אימות Windows

אפשר לבצע שילוב עם שירות מנוהל ל-Microsoft AD במהלך יצירת מופע, וכך להפעיל אימות Windows עבור המופע. כדי לבצע שילוב, בוחרים דומיין שהמופע יצטרף אליו. אם ההצטרפות לדומיין נכשלת, יצירת המופע נכשלת.

לפני שיוצרים מופע עם אימות Windows, כדאי לעיין בטיפים ובמגבלות ובחלופות.

מכונה וירטואלית עם כתובת IP ציבורית נתמכת, כל עוד יש לה גם כתובת IP פרטית. צריך להפעיל את כתובת ה-IP הפרטית של המכונה. אחר כך תוכלו לבחור אם להשתמש בכתובת IP ציבורית או פרטית כדי להתחבר למופע, בתנאי ששתי האפשרויות זמינות.

אלה האפשרויות ליצירת מכונה שמשולבת עם שירות מנוהל ל-Microsoft AD.

המסוף

  1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

    כניסה לדף Cloud SQL Instances

  2. לוחצים על Create instance.
  3. לוחצים על Choose SQL Server (בחירת שרת SQL).
  4. מזינים שם למופע. אל תכללו בשם המופע מידע רגיש או פרטים אישיים מזהים, כי הוא גלוי מחוץ לארגון. אין צורך לכלול את מזהה הפרויקט בשם המופע. הוא נוצר אוטומטית במקומות המתאימים (לדוגמה, בקובצי היומן).
  5. מזינים את הסיסמה של 'sqlserver' user.
  6. מגדירים את האזור של המופע. שיטות מומלצות לשילוב עם שירות מנוהל ל-Microsoft AD
  7. בקטע Configuration options, מגדירים את האפשרויות הרצויות (אבל מחכים לשלב הבא כדי להגדיר את אפשרויות האימות).
  8. לוחצים על אימות. בתפריט הנפתח להצטרפות לדומיין מנוהל של Active Directory מופיעים כל שירותי Microsoft AD המנוהלים שנוספו בעבר לפרויקט.
  9. בתפריט הנפתח להצטרפות לדומיין מנוהל של Active Directory, בוחרים דומיין.
  10. כשמסיימים לבחור את אפשרויות ההגדרה, לוחצים על יצירה. מערכת Cloud SQL יוצרת באופן אוטומטי חשבון שירות לכל מוצר ולכל פרויקט. אם לחשבון אין את התפקיד המתאים, תתבקשו להעניק לו את התפקיד managedidentities.sqlintegrator.

gcloud

הפקודה הבאה יוצרת מופע שמשולב עם Managed Microsoft AD, ולכן מופעלת בו אימות Windows. מידע על הפקודה הבסיסית ליצירת מופע זמין במאמר יצירת מופעים.

מציינים פרמטר של --active-directory-domain=DOMAIN בפקודה gcloud. לדוגמה, מציינים את הפרטים הבאים: --active-directory-domain=ad.mydomain.com

הנה אב טיפוס של הפקודה gcloud:

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

Terraform

כדי ליצור מכונה שמשולבת עם שירות מנוהל ל-Microsoft AD, משתמשים במשאב של Terraform.

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

באמצעות API בארכיטקטורת REST, אפשר ליצור מכונה שמשולבת עם שירות מנוהל ל-Microsoft AD. מציינים דומיין, כמו subdomain.mydomain.com, בשדה domain, כמו שמוצג באב-טיפוס הזה של בקשה:

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

עדכון מכונה עם אימות Windows

אפשר לעדכן את הדומיין של מופע קיים, לשנות או להוסיף דומיין.

מידע כללי על עדכון מכונה זמין במאמר עריכת מכונות.

אם מופע מצורף כרגע לדומיין Managed AD, המופע מבוטל תחילה מהדומיין הזה לפני שהוא מצורף לדומיין החדש. אם העדכון נכשל, יכול להיות שלא תהיה יותר אפשרות להצטרף למופע בדומיין כלשהו.

המסוף

  1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

    כניסה לדף Cloud SQL Instances

  2. כדי לפתוח את הדף סקירה כללית של מכונה, לוחצים על שם המכונה.
  3. לוחצים על Edit.
  4. לוחצים על אימות. בתפריט הנפתח Join an Active Directory domain (הצטרפות לדומיין של Active Directory) מופיעה רשימה של שירות מנוהל ל-Microsoft AD שנוספו בעבר לפרויקט.
  5. בתפריט הנפתח להצטרפות לדומיין מנוהל של Active Directory, בוחרים דומיין חדש (חלופי) למופע.
  6. לוחצים על Save כדי לעדכן את השינויים.

gcloud

הדוגמה הבאה היא אב-טיפוס של פקודה לעדכון מופע קיים. הפקודה מוסיפה או מחליפה דומיין. מעבירים את --active-directory-domain=DOMAIN לפקודה, באופן הבא:

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

REST

באמצעות API בארכיטקטורת REST, אפשר לעדכן מופע קיים. מציינים דומיין, כמו subdomain.mydomain.com, בשדה domain. זוהי דוגמה לבקשה:

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

שילוב עם דומיין AD מנוהל בפרויקט אחר

אפשר לשלב את המופע עם דומיין של שירות מנוהל ל-Microsoft AD שנמצא בפרויקט אחר.

במהלך תכנון השילוב, כדאי לעיין במגבלות.

הפעלת קישור בין רשתות שכנות (peering) בין דומיינים

לפני שממשיכים לשלבים שבהמשך, צריך להפעיל שיוך דומיינים כדי שהדומיין יהיה זמין לכל הפרויקטים הנדרשים עם מכונות Cloud SQL ל-SQL Server.

כדי לקבל רשימה של דומיינים מפרויקטים אחרים שכבר זמינים, אפשר לציין את הפרטים הבאים:

`gcloud active-directory peerings list`

מידע נוסף זמין במאמר בנושא רשימת דומיינים שמוגדרים כעמיתים.

הפקודה gcloud active-directory peerings list דורשת את ההרשאה managedidentities.peerings.list. התפקידים הבאים כוללים את ההרשאה הזו:

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

למידע נוסף ראו את המאמר בקרת גישה באמצעות IAM.

יצירה של חשבון שירות

חוזרים על השלבים האלה לכל פרויקט שמכיל מופע Cloud SQL ל-SQL Server שרוצים לשלב.

  1. קוראים את מידע הרקע על יצירת חשבונות שירות.

  2. כדי ליצור חשבון שירות, משתמשים בפקודה שדומה לפקודה הבאה. מציינים את מזהה הפרויקט שמכיל מופעים של Cloud SQL ל-SQL Server:

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

  3. מקצים את התפקיד managedidentities.sqlintegrator בפרויקט עם שירות מנוהל ל-Microsoft AD. מציינים את מזהה הפרויקט שמכיל את מופע שירות מנוהל ל-Microsoft AD:

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

הפעלת אימות Windows חוצה-פרויקטים

אפשר לבצע אינטגרציה עם דומיין AD בפרויקט אחר באמצעות פקודות gcloud או Cloud SQL API בארכיטקטורת REST. בכל מקרה, צריך לציין את שם המשאב המלא של הדומיין.

כשיוצרים או מעדכנים מופע של Cloud SQL ל-SQL Server, צריך לציין את שם המשאב המלא של הדומיין. יש תמיכה בשני פורמטים:

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

לדוגמה, אם משתמשים ב-gcloud:

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

אם משתמשים בשם קצר של משאב דומיין (למשל DOMAIN_NAME), המערכת מניחה ששירות מנוהל ל-Microsoft AD נמצא באותו פרויקט כמו מכונות Cloud SQL ל-SQL Server.

מגבלות לשילוב עם פרויקטים שונים

אם אתם משלבים עם דומיין AD מנוהל בפרויקט אחר, חלים האילוצים הבאים:

  • עד 10 רשתות עם מופעים של Cloud SQL ל-SQL Server יכולות לשתף מופע מנוהל אחד של Microsoft AD שנמצא בפרויקט אחר.
  • Google Cloud המסוף תומך רק במופעים של שירות מנוהל ל-Microsoft AD שנמצאים באותו פרויקט. במקום להשתמש במסוף Google Cloud , אפשר לבצע שילוב באמצעות פקודות gcloud או Cloud SQL API בארכיטקטורת REST.
  • אם משתמשים ב-VPC Service Controls, מכונות Cloud SQL ל-SQL Server ומכונת שירות מנוהל ל-Microsoft AD צריכות להיות באותם גבולות גזרה.

בנוסף, אם מופע משולב עם דומיין מנוהל של AD בפרויקט אחר, יכול להיות ששם הדומיין המוגדר במלואו (FQDN) שמוצג במסוףGoogle Cloud יהיה לא מדויק לגבי המופע הזה. באופן ספציפי, בדף Overview של המופע הזה, בקטע Connect to this instance, שמות הדומיין המלאים עשויים להכיל מחרוזות שמופרדות באמצעות לוכסנים, שאפשר להתעלם מהן. לדוגמה, שם FQDN לא מדויק יכול להופיע כך:

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

במקרה כזה, ה-FQDN המדויק הוא: 

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

הסרת אימות Windows ממופע

אפשר להסיר אימות של Windows, וכך גם שילוב של שירות מנוהל ל-Microsoft AD, ממופע קיים.

המסוף

  1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

    כניסה לדף Cloud SQL Instances

  2. כדי לפתוח את הדף סקירה כללית של מכונה, לוחצים על שם המכונה.
  3. לוחצים על Edit.
  4. לוחצים על אימות. בתפריט הנפתח להצטרפות לדומיין מנוהל של Active Directory מופיעה רשימה של שירותי מנוהלים ל-Microsoft AD שנוספו בעבר לפרויקט.
  5. בתפריט הנפתח, בוחרים באפשרות No domain/Join later (אין דומיין / הצטרפות מאוחרת יותר) עבור המופע.
  6. קוראים את ההודעה על הפעלה מחדש של המכונה, ולוחצים על סגירה.
  7. לוחצים על Save כדי לעדכן את השינויים.

gcloud

כדי להסיר מופע מדומיין, וכך להסיר את אימות Windows, צריך להשתמש בערך ריק לדומיין. כלומר, בפקודה, משתמשים בערך ריק לפרמטר --active-directory-domain, באופן הבא:

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

REST

באמצעות ה-API בארכיטקטורת REST, אפשר להסיר מופע מדומיין. מציינים ערך ריק בשדה domain, באופן הבא:

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

התחברות למכונה באמצעות משתמש

ב-Cloud SQL ל-SQL Server, משתמש ברירת המחדל הוא sqlserver.

אחרי שמשלבים מופע עם שירות מנוהל ל-Microsoft AD, אפשר להתחבר למופע עם המשתמש sqlserver, באופן הבא:

  1. יוצרים התחברות ל-SQL Server על סמך משתמש או קבוצה ב-Windows, באופן הבא:

    CREATE LOGIN [domain\user_or_group] FROM WINDOWS

  2. מתחברים למופע באמצעות אימות Windows, עם שם ה-DNS של המופע. דוגמאות לשמות DNS של מופעים שאפשר לציין:

    • כדי להתחבר באמצעות כתובת IP פרטית: 

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

    • כדי להתחבר באמצעות כתובת IP ציבורית: 

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

    • כדי להתחבר באמצעות שרת proxy ל-Cloud SQL Auth (ראו גם בהמשך): 

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

    אם משתמשים בכתובת ה-IP של המכונה, צריך להגדיר את לקוחות Kerberos כך שיתמכו בשמות מארחים של כתובות IP. ‫Cloud SQL לא תומך בהתחברות מדומיינים שמחוברים באמצעות יחסי אמון.

שימוש בשרת proxy ל-Cloud SQL Auth עם אימות Windows

אפשר להשתמש בשרת proxy ל-Cloud SQL Auth עם השילוב של שירות מנוהל ל-Microsoft AD.

לפני שמתחילים, כדאי לעיין במידע הבא:

שלבים לאימות Windows

מידע נוסף על הפעלת שרת proxy ל-Cloud SQL Auth זמין במאמר בנושא הפעלת שרת proxy ל-Cloud SQL Auth.

כדי להשתמש באימות Windows, צריך להריץ את שרת ה-proxy ל-Cloud SQL Auth ביציאה 1433. כדי למפות רשומה מוגדרת מראש של שם שירות ראשי (SPN) לכתובת של שרת proxy ל-Cloud SQL Auth, משתמשים בפקודה:

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

הפעלת שרת proxy ל-Cloud SQL Auth באופן מקומי

אם מריצים את Cloud SQL Auth Proxy באופן מקומי, צריך להשתמש בקובץ המארחים כדי למפות את הערכים הבאים ל-127.0.0.1:

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

לדוגמה, אפשר להוסיף את השורה הבאה לקובץ hosts (למשל, ל-c:\windows\system32\drivers\etc\hosts):

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

בדוגמה הזו, אפשר להריץ את שרת ה-proxy ל-Cloud SQL Auth באמצעות הפקודה הזו, ולהפוך אותו לזמין ב-127.0.0.1:1433:

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

הפעלת שרת proxy ל-Cloud SQL Auth שלא באופן מקומי

כדי להריץ את שרת ה-proxy ל-Cloud SQL Auth שלא באופן מקומי, פועלים לפי ההוראות שבמאמר הפעלת שרת ה-proxy ל-Cloud SQL Auth באופן מקומי, אבל משתמשים בערך אחר בקובץ hosts.

לדוגמה, אם מארח לא מקומי הוא MyOtherHost, אפשר להוסיף את השורה הבאה לקובץ המארחים:

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

פתרון בעיות שקשורות לגיבוי NTLM בלקוחות

אם אתם משתמשים באימות Windows ובכתובת IP של מופע כדי להתחבר למופע, אתם צריכים להגדיר לקוח Kerberos כדי לתמוך בשמות מארחים של כתובות IP.

‫Cloud SQL לא תומך באימות NTLM, אבל יכול להיות שחלק מלקוחות Kerberos ינסו לחזור אליו. כפי שמוסבר בקטע הזה, אם מנסים להתחבר באמצעות SQL Server Management Studio‏ (SSMS) ומופיעה הודעת השגיאה הבאה, סביר להניח שהסיבה לכך היא חזרה ל-NTLM:

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

NTLM הוא קבוצה של פרוטוקולי אבטחה של מיקרוסופט לאימות. אפשר גם לעיין בסיבות למעבר חזרה ל-NTLM.

אימות של חזרה ל-NTLM עבור לקוח Windows

כדי לוודא שחזרה ל-NTLM גרמה לשגיאה ב-Windows:

  1. מתחברים באמצעות פרטי הכניסה הרצויים בשרת המקומי (לא משתמשים באפשרות 'הפעלה כ...').
  2. פותחים שורת פקודה.
  3. מריצים את klist purge.
  4. מ-SSMS, מנסים להתחבר ל-SQL Server באמצעות אימות Windows.
  5. מריצים את klist ובודקים אם הונפק כרטיס ל-"MSSQLSvc/<address>:1433 @ domain".
  6. אם אין כרטיס כזה, סביר להניח שהשגיאה נגרמת ממעבר חזרה ל-NTLM.
  7. אם יש כרטיס כזה, צריך לוודא שמנהל ההתקן של SQL Server לא מחייב אימות NTLM. כדאי גם לבדוק אם אימות NTLM נאכף באמצעות מדיניות קבוצתית.

אימות של חזרה ל-NTLM עבור לקוח Linux

כדי לוודא שחזרה ל-NTLM גרמה לשגיאה ב-Ubuntu 16.04, צריך לפעול לפי השלבים שבקטע הזה. השלבים דומים לאלה של הפצות אחרות של Linux.

הגדרת אימות Kerberos

  1. הגדרת לקוח Kerberos:

    sudo apt-get install krb5-user

  2. כשמוצגת בקשה להזין את התחום שמוגדר כברירת מחדל, מקלידים שם דומיין מקומי באותיות רישיות.

  3. מריצים את הפקודה הבאה כדי להתקין את כלי שורת הפקודה של SQL Server:

    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

התחברות באמצעות אימות Windows

  1. מריצים את הכלי kinit באופן הבא: kinit <user_account>
  2. כדי להתחבר באמצעות אימות Windows, מריצים את הפקודה: /opt/mssql-tools/bin/sqlcmd -S <address >>
  3. מריצים את הפקודה klist ובודקים אם הונפק כרטיס במיוחד עבור: "MSSQLSvc/<address>:1433 @ domain"
  4. אם הכרטיס לא הונפק, סביר להניח שהשגיאה שלמעלה מצביעה על בעיה שגורמת לחזרה ל-NTLM.

הסיבות למעבר חזרה ל-NTLM

חזרה ל-NTLM היא טעות בהגדרת הלקוח שיכולה להיות קשורה לתנאים הבאים:

  • כברירת מחדל, מערכת Windows לא מנסה לבצע אימות Kerberos למארח אם שם המארח הוא כתובת IP. כדי להפעיל אימות Kerberos מהדומיין המנוהל, אפשר לנסות את השיטה שמתוארת במסמכי התיעוד של מיקרוסופט. השיטה הזו לא פועלת עם פרטי כניסה מקומיים כשחובה להשתמש ב-FQDN.
  • אימות Kerberos באמצעות יחסי אמון חיצוניים לא פועל. במקום זאת, צריך להשתמש ביחסי אמון בין יערות, כפי שמתואר כאן.
  • אימות Kerberos דורש ניתוב של סיומות שמות כדי לאפשר את האיתור של שירותים ביער אחר. אפשר לנסות את השיטה שמתוארת כאן.
  • אימות Kerberos לא פועל אם לא רשום SPN לשירות. כדי להתחבר באמצעות אימות Windows, צריך להשתמש רק ב-FQDN או בכתובות IP שמתקבלות מ Google Cloud המסוף.

משתמשים ב-AD מקומי: יצירת כניסה ל-Windows

אפשר להשתמש במשתמש AD מקומי כדי ליצור התחברות ל-Windows ב-Cloud SQL ל-SQL Server.

לדוגמה, אפשר להתחבר באמצעות SQL Server Management Studio ‏(SMSS) שפועל במכונת Windows וירטואלית שמארחת בענן הווירטואלי הפרטי (VPC) של Google Cloud הפרויקט.

בהקשר הזה, Cloud SQL ל-SQL Server תומך רק בפרוטוקול Kerberos לאימות Windows. באימות Windows שמבוסס על Kerberos, הלקוח צריך לפתור את שם ה-DNS של AD מקומי ושל Managed Microsoft AD.

הגדרת הרשאות שיתוף חד-סטריות או דו-סטריות

קודם כל, מחליטים אם רוצים להשתמש ביחסי אמון חד-כיווניים או דו-כיווניים.

לאחר מכן, פועלים לפי ההוראות ליצירת יחסי אמון בין דומיין AD מקומי לבין דומיין Managed Microsoft AD.

הגדרה של מכונה וירטואלית של Windows ויצירת פרטי כניסה ל-Windows

אחרי שיוצרים יחסי אמון בין דומיין AD מקומי לבין שירות מנוהל ל-Microsoft AD, מבצעים את השלבים הבאים. לדוגמה, ההוראות האלה מתייחסות ל-SQL Server Management Studio ‏ (SSMS), שפועל במכונה וירטואלית של Windows, שמארחת את ה-VPC של הפרויקט: Google Cloud

  1. יוצרים מכונה וירטואלית של Windows.
  2. מצטרפים למכונה הווירטואלית של Windows לשירות מנוהל ל-Microsoft AD.
  3. מתקינים את SSMS במכונה הווירטואלית של Windows.
  4. לפתור את הבעיה בדומיין המקומי ברשת ה-VPC.
    • ברשת המורשית שבה פועלת המכונה הווירטואלית של Windows, מפעילים את פענוח ה-DNS המקומית באמצעות השלבים שמופיעים בדף פתרון שאילתות לאובייקטים של Microsoft AD לא מנוהלים. השלבים בדף הזה הם תנאים מוקדמים לאימות Windows מבוסס Kerberos, כדי שמשתמשים מקומיים יוכלו להשתמש בו.

  5. יוצרים פרטי כניסה ל-Windows עבור משתמש מקומי.

    CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS

  6. מתחברים למכונה של Cloud SQL ל-SQL Server באמצעות ההוראות הספציפיות לאפליקציה להתחברות של משתמש מקומי. לדוגמה, אם אתם משתמשים ב-SQL Server Management Studio, כדאי לעיין בהוראות האלה.

אם מתרחשת בעיה במהלך התחברות למכונה של Cloud SQL ל-SQL Server, צריך לבצע את הבדיקות הבאות:

  • מאמתים את הגדרות חומת האש של הרשת המקומית ושל ה-VPC עם הרשאת הפרויקט, באמצעות ההוראות ליצירת יחסי אמון עם דומיין מקומי.
  • בודקים את ניתוב סיומות השמות עבור יחסי האמון המקומיים.
  • מוודאים שאפשר לבצע את פעולות פענוח ה-DNS מהמכונה הווירטואלית של Windows שבה פועל SSMS:
    • nslookup fqdn-for-managed-ad-domain
    • nslookup fqdn-for-on-premises-ad-domain
    • nslookup fqdn-for-cloud-sql-server-instance

טיפים

  • מכונה עם כתובת IP ציבורית נתמכת, כל עוד יש לה גם כתובת IP פרטית. צריך להפעיל את כתובת ה-IP הפרטית במכונה. אחר כך תוכלו לבחור אם להשתמש בכתובת IP ציבורית או פרטית כדי להתחבר למכונה, כל עוד שתיהן זמינות.
  • לפני שיוצרים מופע, כולל מופע חלופי, כדאי לעיין במידע הבא לפי הצורך:
  • ‫Terraform נתמך.
  • אם מופיעה אחת מהשגיאות הבאות, צריך לוודא שכל הדרישות המוקדמות לשילוב מתקיימות:
    • ‫"Per-Product Per-Project Service Account is not found"
    • "אין הרשאה מספקת לשילוב עם דומיין של Managed Service for Microsoft Active Directory"
  • אם מופיעה השגיאה 'הדומיין לא נמצא', צריך לוודא ששם הדומיין נכון (הוא תלוי באותיות רישיות).
  • אם אימות Windows נכשל מדומיין שמחובר דרך יחסי אמון, צריך לוודא שאימות Windows פועל עבור משתמש מדומיין מנוהל. אם כן:
    1. מוודאים שהשתמשתם בשם DNS. אין תמיכה בכתובות IP מדומיינים שמקושרים באמצעות יחסי אמון.
    2. חשוב לוודא שפעלתם לפי כל השלבים ליצירת יחסי אמון עם דומיין מקומי, כולל פתיחת כל היציאות בחומת האש.
    3. מאמתים את המהימנות.
    4. מוודאים שכיוון היחסים מאפשר למשתמשים מהדומיין (שמחובר באמצעות יחסי אמון) לבצע אימות בדומיין המנוהל.
    5. מוודאים שניתוב סיומת השם מוגדר בדומיין שמחובר באמצעות יחסי אמון.
    6. מוודאים שהאמון פועל בלי להשתמש ב-Cloud SQL ל-SQL Server:
      1. יוצרים מכונה וירטואלית של Windows.
      2. מצטרפים לדומיין של שירות מנוהל ל-Microsoft AD.
      3. לדוגמה, נסו להפעיל את פנקס הרשימות כמשתמש מהדומיין שמחובר באמצעות יחסי אמון.
    7. מפעילים מחדש את מכונת ה-VM של הלקוח ובודקים מחדש את אימות Windows.
  • יכול להיות שתנסו ליצור התחברות ל-SQL Server, אבל תקבלו את השגיאה הבאה: "לא נמצא משתמש או קבוצה של Windows NT domain\name. כדאי לבדוק שוב את השם". יכול להיות שהבעיה נובעת מכך שקבוצות מקומיות בדומיין לא נתמכות. אם זה המקרה, צריך להשתמש במקום זאת בקבוצות גלובליות או אוניברסליות.
  • כשמשתמש שולח שאילתות SQL Server מדומיין שמחובר באמצעות יחסי אמון, יכולה להופיע השגיאה הבאה: 'לא ניתן לאחזר מידע על קבוצת משתמשים או משתמש ב-Windows NT'. לדוגמה, השגיאה הזו יכולה להתרחש אם אתם יוצרים התחברויות מדומיינים שמקושרים באמצעות יחסי אמון. השגיאה יכולה להתרחש גם אם מעניקים הרשאות להתחברויות מדומיינים שמחוברים באמצעות יחסי אמון. במקרים כאלה, לרוב אפשר לפתור את הבעיה על ידי ניסיון חוזר לבצע את הפעולה. אם הניסיון החוזר נכשל, סוגרים את החיבור ופותחים חיבור חדש.

  • אם מופיעה השגיאה 'לא ניתן לקבל מידע על קבוצת משתמשים או משתמש ב-Windows NT', צריך לבדוק את קישוריות הרשת לדומיינים מקומיים באמצעות קובץ היומן active_directory.log שזמין ב-Cloud Logging עבור מכונת Cloud SQL ל-SQL Server. הקובץ הזה מכיל את נתוני האבחון הבאים לגבי שינויים בקישוריות לדומיין המקומי:

    • תחומים מקומיים מהימנים על ידי מופע Cloud SQL ל-SQL Server. לדוגמה, ביומן הבא מוצג השינוי ממצב שבו אין דומיינים מהימנים למצב שבו יש שני דומיינים מהימנים חדשים, כשמות NetBIOS שלהם, ONPREM ו-CHILD:
      ‫
      2023-06-12 20:55:09.975 Detected change in trusted onprem domains: Previously trusted onprem domains: []. Current trusted onprem domains: [ONPREM CHILD]
       אם דומיין מקומי לא מופיע או שהוא מתועד כלא מהימן, צריך לבדוק אם קיימת מהימנות עם דומיין Managed AD והאם היא מאומתת. אם יש יחסי אמון חד-כיווניים בין דומיין Managed AD לבין דומיין מקומי, יכול להיות שדומיינים מקומיים אחרים שדומיין מקומי נותן בהם אמון לא יהיו גלויים.
    • אפשר להגיע לדומיינים מקומיים ואפשר להגיע לדומיינים מקומיים באמצעות פינג רגיל ממופע Cloud SQL ל-SQL Server. לדוגמה, ביומן הבא מוצג השינוי מאין דומיינים שאפשר להגיע אליהם לשני דומיינים חדשים שאפשר להגיע אליהם, onprem.com ו-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]
       אם דומיין לא מופיע ביומני הנגישות, צריך לוודא שהוא רשום קודם כדומיין מהימן. אחרת, לא מתבצעת בדיקה של יכולת ההגעה. תמיד יש VPC Peering בין פרויקט עם מופעים מקומיים לבין Google Cloud פרויקטים. אם יש עוד קישור VPC אחד, נוצר קישור מעבר בין רשתות שכנות, שלא נתמך ב-Cloud SQL. במקום זאת, מומלץ להשתמש במנהרת VPN כדי לחבר דומיין מקומי ל-Cloud SQL. צריך להיות לכל היותר חיבור אחד של קישור בין רשתות שכנות (peering) בין הפרויקט המקומי לבין Google Cloud הפרויקט עם המכונות של Cloud SQL ל-SQL Server.
    • פינגים מוצלחים ולא מוצלחים של Microsoft remote procedure call (MSRPC) לדומיינים מקומיים ממופע Cloud SQL ל-SQL Server. לדוגמה, ביומן הבא מוצג השינוי ממצב שבו אין דומיינים שאפשר לבצע להם פינג של MSRPC למצב שבו יש שני דומיינים חדשים שאפשר לבצע להם פינג של MSRPC‏, ONPREM ו-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 נכללים כאבחון נוסף, ויכול להיות שהם לא יפעלו בחלק מההגדרות. עדיין אפשר לאמת את הקישוריות של דומיין מקומי באמצעות שני האבחונים הראשונים.

  • אם שאילתות של SQL Server מחזירות את השגיאה 'ההתחברות היא מדומיין לא מהימן', חשוב לדעת שכתובות IP לא נתמכות עבור משתמשים מדומיינים שמחוברים דרך יחסי אמון. בנוסף, הפעולות הבאות עשויות לפתור את הבעיה:

    • אם כתובת IP משמשת לחיבור משתמשים מדומיין מנוהל, צריך לפעול לפי ההוראות האלה.
    • הימנעו משימוש בשרתי proxy, והשתמשו תמיד באותו שם DNS כדי להתחבר ל-Cloud SQL ל-SQL Server, כפי שמופיע השם ב Google Cloud מסוף.
    • מבצעים ניקוי של כרטיסי Kerberos הקיימים. יכול להיות שהשגיאה שלמעלה תופיע אם היה לכם לקוח שהתחבר לאחרונה למכונת Cloud SQL ל-SQL Server והמכונה הופסקה והופעלה. לחלופין, השגיאה עשויה להתרחש אם האימות של Windows הושבת ואז הופעל מחדש עבור מופע Cloud SQL ל-SQL Server. אם הלקוח משתמש במטמון של פרטי הכניסה של Windows, צריך לנעול ולבטל את הנעילה של תחנת העבודה של הלקוח, או להריץ את הפקודה klist purge.

  • ניסיון להפעיל אימות של Windows עשוי להוביל לשגיאה: "למופע הזה נדרש תאריך יצירה עדכני יותר כדי לתמוך בשירות מנוהל עבור Microsoft Active Directory". כמה נקודות חשובות לגבי השגיאה הזו:

    • ב-Cloud SQL, אם נוצר מופע של Cloud SQL ל-SQL Server בתאריך 12 במרץ 2021 או לפני כן, אי אפשר לשלב אותו עם שירות מנוהל ל-Microsoft AD.
    • במקרים מסוימים, אם יוצרים מכונת Cloud SQL ל-SQL Server ולא מפעילים את שירות מנוהל ל-Microsoft AD בזמן היצירה, יכול להיות שתופיע אותה שגיאה. אחרי שתעיינו בטיפים האחרים שבקטע הזה, תוכלו ליצור מופע חדש ולהפעיל את שירות מנוהל ל-Microsoft AD בזמן יצירת המופע.

  • ניסיון ליצור מכונה של Cloud SQL ל-SQL Server עלול להוביל לשגיאה 'המכונה הזו לא תומכת בשירות מנוהל ל-Microsoft Active Directory'. אם השגיאה הזו מופיעה, יכול להיות שהפרויקט לא נתמך. כדאי לנסות להשתמש בפרויקט אחר.

  • אם יש מופע עם בעיות מתמשכות באימות Windows (בין אם המופע עודכן לאחרונה ובין אם לא), נסו לבטל את ההצטרפות לדומיין המנוהל של Active Directory ואז להצטרף אליו מחדש. כדי לעשות זאת, צריך להשתמש בתהליך העדכון כדי לבטל את ההצטרפות לדומיין ואז להצטרף אליו מחדש. הפעולה הזו לא מסירה משתמשים או התחברויות קיימים שאומתו ב-Windows ומאוחסנים במסדי הנתונים שלכם. עם זאת, הסרת אימות Windows גורמת להפעלה מחדש של מופע.

  • אפשר להשתמש בכלי לאבחון AD כדי לפתור בעיות בהגדרת AD בדומיין המקומי ובמופעים של Cloud SQL ל-SQL Server במסוף Google Cloud .

פתרון בעיות

כדי לקבל פרטים, לוחצים על הקישורים בטבלה:

לגבי השגיאה הזו... יכול להיות שהבעיה היא... אפשר לנסות את הפעולות הבאות…
Per-product, per-project service account not found. השם של חשבון השירות שגוי. בדף Service Accounts, מוודאים שיצרתם חשבון שירות לפרויקט המשתמש הנכון.
Insufficient permission to integrate with Managed Service for Microsoft Active Directory domain. התפקיד managedidentities.sqlintegrator חסר בחשבון השירות. בדף IAM and Admin, מוסיפים את התפקיד managedidentities.sqlintegrator לחשבון השירות.
Domain not found. הדומיין לא קיים או שהייתה טעות בהקלדה. חשוב לוודא ששם הדומיין נכון. הוא תלוי אותיות רישיות.
The domain is busy with another operation. Please retry. מופע אחר של Cloud SQL מריץ פעולה באותו דומיין מנוהל של Active Directory. מנסים שוב לבצע את הפעולה. אם מבצעים עדכונים בכמה מכונות Cloud SQL שמחוברות לאותו דומיין, כדאי להגביל את מספר העדכונים שמבוצעים במקביל.
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. לא ניתן היה לבצע את העדכונים הנדרשים בדומיין המנוהל של Active Directory. אם נתקלתם בבעיות באימות Windows, אתם יכולים לנסות לבטל את ההצטרפות לדומיין המנוהל של Active Directory ואז להצטרף אליו מחדש. כדי לעשות זאת, משתמשים ב תהליך העדכון כדי לבטל את ההצטרפות לדומיין ואז להצטרף אליו מחדש. הפעולה הזו לא תסיר משתמשים או התחברויות קיימים שאומתו ב-Windows ומאוחסנים במסדי הנתונים שלכם. עם זאת, הסרת האימות של Windows גורמת להפעלה מחדש של מופע.
This instance would need a more recent creation date to support Managed Service for Microsoft Active Directory. ב-Cloud SQL, אם נוצר מופע Cloud SQL ל-SQL Server בתאריך 12 במרץ 2021 או לפני כן, אי אפשר לשלב אותו עם שירות מנוהל ל-Microsoft AD. נסו לבצע את הפעולה במופע שנוצר אחרי 12 במרץ 2021.

המאמרים הבאים

  • חשוב לוודא שקראתם את דף הסקירה הכללית, שכולל מגבלות ותכונות שלא נתמכות. בדף הזה יש גם קישורים לתיעוד נוסף.