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

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

• שילוב עם שירות מנוהל ל-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.

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

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
}

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

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

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

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

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

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

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

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

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

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

הפעלת שיתוף פעולה בין דומיינים

לפני שממשיכים לשלבים שבקטעים הבאים, צריך להפעיל שיתוף דומיינים כדי שהדומיין יהיה זמין לכל הפרויקטים הנדרשים עם מכונות 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, יכול להיות שה-FQDNs יכילו מחרוזות שמופרדות באמצעות לוכסנים, שאפשר להתעלם מהן. לדוגמה, שם דומיין מלא לא מדויק יכול להופיע כך:

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

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

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

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

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

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-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.

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

• מידע על שרת proxy ל-Cloud SQL Auth

• התחברות באמצעות שרת proxy ל-Cloud SQL Auth

שלבים לאימות ב-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. מנסים להתחבר ל-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 עבור משתמש מקומי.

   • פועלים לפי ההוראות ליצירת פרטי התחברות כדי ליצור פרטי התחברות ל-Windows עבור משתמש מקומי. לדוגמה, מציינים פקודה דומה לפקודה הבאה:

   CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS
   

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

פתרון בעיות שקשורות למשתמש AD מקומי

אם מתרחשת בעיה במהלך התחברות למכונה של 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 ציבורית או פרטית כדי להתחבר למכונה, בתנאי ששתי האפשרויות זמינות.
• לפני שיוצרים מופע, כולל מופע חלופי, צריך לעיין במידע הבא לפי הצורך:
  • מידע על שימוש בכתובת 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. צריך להיות לכל היותר חיבור אחד של קישור בין רשתות שכנות (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 .

פתרון בעיות

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

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

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