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

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

  • שילוב עם Managed Service for Microsoft Active Directory (שנקרא גם Managed 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.
  4. מזינים שם למופע. אל תכללו בשם המופע מידע רגיש או פרטים אישיים מזהים, כי הוא גלוי מחוץ לארגון. אין צורך לכלול את מזהה הפרויקט בשם המופע. הוא נוצר אוטומטית במקומות המתאימים (לדוגמה, בקובצי היומן).
  5. מזינים את הסיסמה של 'sqlserver' המשתמש.
  6. מגדירים את האזור של המופע. שיטות מומלצות לשילוב עם שירות מנוהל ל-Microsoft AD
  7. בקטע Configuration options (אפשרויות הגדרה), מגדירים את האפשרויות הרצויות (אבל מחכים לשלב הבא כדי להגדיר את אפשרויות האימות).
  8. לוחצים על אימות. בתפריט הנפתח של הצטרפות לדומיין מנוהל של Active Directory מופיעים כל הדומיינים המנוהלים של Microsoft AD שנוספו בעבר לפרויקט.
  9. בתפריט הנפתח להצטרפות לדומיין מנוהל של Active Directory, בוחרים דומיין.
  10. כשמסיימים לבחור את אפשרויות ההגדרה, לוחצים על יצירה. מערכת Cloud SQL יוצרת באופן אוטומטי חשבון שירות לכל מוצר ולכל פרויקט. אם לחשבון אין את התפקיד המתאים, תתבקשו להעניק לו את התפקיד managedidentities.sqlintegrator.

gcloud

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

מציינים פרמטר של --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 for SQL Server ומופע מנוהל של Microsoft AD צריכים להיות ממוקמים באותו מתחם.

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

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]

לדוגמה, אפשר להוסיף את השורה הבאה לקובץ המארחים (למשל, ל-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. מנסים להתחבר ל-SQL Server באמצעות אימות Windows מ-SSMS.
  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 מקומי לבין דומיין שירות מנוהל ל-Microsoft AD.

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

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

  1. יוצרים מכונה וירטואלית של Windows.
    • יוצרים מכונה וירטואלית עם גרסה של Windows שנתמכת על ידי שירות מנוהל ל-Microsoft AD.
    • יוצרים את המכונה הווירטואלית בפרויקט שמארח את הדומיין של שירות מנוהל ל-Microsoft AD. אם יש VPC משותף שהוא רשת מורשית, אפשר גם ליצור את המכונה הווירטואלית בכל אחד מפרויקטי השירות שלו.
    • יוצרים את המכונה הווירטואלית ברשת VPC שהיא רשת מורשית של דומיין שירות מנוהל ל-Microsoft AD, ומוגדרת בה גישה פרטית לשירותים ל-Cloud SQL.
  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"
    • "אין הרשאה מספקת לשילוב עם דומיין של שירות מנוהל ל-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]
       אם דומיין מקומי לא מופיע או שהוא מתועד כלא מהימן, צריך לבדוק אם קיים אמון בדומיין המנוהל של Active Directory והאם הוא מאומת. אם יש יחסי אמון חד-כיווניים בין דומיין 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. צריך להיות לכל היותר חיבור אחד של קישוריות בין הפרויקט המקומי לבין הפרויקט 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 עלול להוביל לשגיאה 'למופע הזה נדרש תאריך יצירה עדכני יותר כדי לתמוך ב-Managed Service for 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.

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

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