סקירה כללית של שירות מנוהל ל-Microsoft AD ב-Cloud SQL

אפשר לשלב את Cloud SQL ל-SQL Server עם שירות מנוהל ל-Microsoft Active Directory (שנקרא גם שירות מנוהל ל-Microsoft AD).

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

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

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

שילוב של Cloud SQL ל-SQL Server עם דומיין AD מספק יתרון נוסף של שילוב עם הענן של דומייני AD מקומיים.

דרישות מוקדמות לשילוב

אפשר לבצע אינטגרציה עם שירות מנוהל ל-Microsoft AD, להוסיף תמיכה באימות Windows למופע. עם זאת, לפני השילוב, צריך לוודא שGoogle Cloud הפרויקט שלכם עומד בדרישות הבאות:

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

אתם צריכים חשבון שירות לכל מוצר ולכל פרויקט, לכל פרויקט שאתם מתכננים לשלב עם שירות מנוהל ל-Microsoft AD. משתמשים ב-gcloud או ב-Console כדי ליצור את החשבון ברמת הפרויקט. צריך להקצות לחשבון השירות 'לכל מוצר, לכל פרויקט' את התפקיד managedidentities.sqlintegrator בפרויקט. מידע נוסף זמין במאמר בנושא gcloud projects set-iam-policy.

אם אתם משתמשים במסוף Google Cloud , מערכת Cloud SQL יוצרת בשבילכם באופן אוטומטי חשבון שירות ומבקשת מכם להעניק את התפקידmanagedidentities.sqlintegrator.

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

gcloud beta services identity create --service=sqladmin.googleapis.com \
    --project=PROJECT_NUMBER

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

    service-PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com

לדוגמה, שם של חשבון שירות:

    service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com

כדי להעניק את ההרשאה הנדרשת לשילוב, צריך הרשאות קיימות. ההרשאות הנדרשות מפורטות במאמר ההרשאות הנדרשות.

כדי להעניק את ההרשאה הנדרשת לשילוב, מריצים את הפקודה הבאה. אם שירות מנוהל ל-Microsoft AD נמצא בפרויקט אחר, AD_PROJECT_ID צריך להיות הפרויקט שמכיל את המכונה של שירות מנוהל ל-Microsoft Active Directory, ו-SQL_PROJECT_NUMBER צריך להיות הפרויקט שמכיל את המכונה של SQL Server:

gcloud projects add-iam-policy-binding AD_PROJECT_ID \
--member=serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com \
--role=roles/managedidentities.sqlintegrator

אפשר גם לעיין במאמר בנושא gcloud beta services identity create.

שיטות מומלצות לשילוב עם שירות מנוהל ל-Microsoft AD

כשמתכננים שילוב, חשוב לבדוק את הנקודות הבאות:

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

טופולוגיות לשילוב עם שירות מנוהל ל-Microsoft AD

‫Cloud SQL ל-SQL Server לא תומך בקבוצות מקומיות בדומיין. עם זאת, אפשר:

  • הוספה של קבוצות גלובליות או של פרטי התחברות של משתמשים בודדים ישירות ב-SQL Server
  • משתמשים בקבוצות אוניברסליות כשכל הקבוצות והמשתמשים שייכים לאותו יער

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

אפשרות 1: הוספת חשבונות משתמשים וקבוצות כהתחברויות ל-SQL Server

אם יש לכם כמה דומיינים בכמה יערות, וכמה קבוצות גלובליות, אתם יכולים להוסיף את כל חשבונות המשתמשים האישיים, וגם את הקבוצות הגלובליות והאוניברסליות, ישירות כהתחברויות ל-SQL Server. דוגמה לאפשרות 1:

טופולוגיית AD, אפשרות 1.

אפשרות 2: הגדרה של קבוצה אוניברסלית באחד מהדומיינים

אם הדומיינים שלכם נמצאים באותו יער, אתם יכולים להגדיר קבוצה אוניברסלית באחד מהדומיינים. אחר כך אפשר להוסיף את כל חשבונות המשתמשים האישיים, ואת הקבוצות הגלובליות והאוניברסליות, כקבוצות צאצא של הקבוצה האוניברסלית שהוגדרה, ולהוסיף את הקבוצה האוניברסלית שהוגדרה כהתחברות ל-SQL Server. דוגמה לאפשרות 2:

טופולוגיה של AD, אפשרות 2.

מגבלות ואפשרויות חלופיות

המגבלות הבאות חלות כשמשלבים עם שירות מנוהל ל-Microsoft AD:

  • קבוצות מקומיות בדומיין לא נתמכות, אבל אפשר להוסיף קבוצות גלובליות או פרטי התחברות של משתמשים ישירות ב-SQL Server. אפשר גם להשתמש בקבוצות אוניברסליות אם כל הקבוצות והמשתמשים שייכים לאותו יער.
  • באופן כללי, למשתמשים חדשים שנוצרו דרך המסוף מוקצה התפקיד Google Cloud , שכולל את תפקיד מסד הנתונים הקבוע של SQL Server Agent: SQLAgentUserRole.CustomerDbRootRole עם זאת, אי אפשר להעניק את התפקיד הזה למשתמשים שנוצרו ישירות דרך SQL Server, כמו משתמשים ב-שירות מנוהל ל-Microsoft AD, או להשתמש ב-SQL Server Agent, כי מסד הנתונים MSDB שבו צריך להעניק את התפקיד הזה מוגן.
  • חלק מהפעולות המוגבלות עשויות להוביל לשגיאה הבאה: "לא ניתן לקבל מידע על קבוצת משתמשים או משתמש ב-Windows NT". דוגמה לפעולה מוגבלת כזו היא יצירת התחברויות על ידי משתמשים מדומיינים שמחוברים באמצעות יחסי אמון. דוגמה נוספת היא הענקת הרשאות למשתמשים מדומיינים שמחוברים באמצעות יחסי אמון. במקרים כאלה, לרוב אפשר לנסות שוב את הפעולה והיא תצליח. אם הניסיון החוזר נכשל, סוגרים את החיבור ופותחים חיבור חדש.
  • שמות דומיין שמוגדרים במלואם (FQDN) לא נתמכים ב-SQL Server ב-Windows. לכן, כשיוצרים התחברויות ל-SQL Server, צריך להשתמש בשמות דומיין (שמות קצרים) ולא ב-FQDN. לדוגמה, אם שם הדומיין הוא ad.mydomain.com, צריך ליצור התחברויות ל-SQL Server עבור ad\user ולא עבור ad.mydomain.com\user.
  • כדי לגשת למכונות של SQL Server, צריך להשתמש תמיד בשמות דומיין מלאים (FQDN). לדוגמה, אפשר להשתמש ב-FQDN שדומה ל-private.myinstance.us-central1.myproject.cloudsql.mydomain.com. אין תמיכה בשמות Netbios, וגם לא בשמות מקוצרים אם לא מציינים סיומות DNS.
  • אי אפשר לנהל התחברויות ל-SQL Server שמבוססות על משתמשים וקבוצות ב-Active Directory ממסוף Google Cloud .
  • ב-Cloud SQL, אם נוצר מופע של SQL Server בתאריך 12 במרץ 2021 או לפני כן, אי אפשר לשלב אותו עם שירות מנוהל ל-Microsoft AD.
  • אימות Windows לא יפעל עם אמון חיצוני. יכול להיות שהשגיאה היא: "שם היעד הראשי שגוי. אי אפשר ליצור הקשר של SSPI". בנוסף, בהתאם להמלצות של מיקרוסופט, צריך להשתמש בהרשאת גישה ליער במקום בהרשאת גישה חיצונית לאימות Kerberos.

נקודות קצה של Active Directory וחיבורי TLS

אם אתם משתמשים באימות Windows ורוצים ליצור חיבור TLS בלי לסמוך על אישור השרת, אתם צריכים להחליף את האישורים אחרי שאימות Windows מופעל במופע.

אם החיבור נכשל ואחד מהאישורים שלכם נוצר לפני 15 במרץ 2025, אתם צריכים להחליף את אישור השרת שוב ולנסות להתחבר שוב.

לא נתמך בשילוב

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

  • קבוצות מקומיות בדומיין.
  • הסרת התחברויות ל-SQL Server של משתמשים מדומיינים שמחוברים דרך יחסי אמון. אפשר לבצע את הפעולה הזו באמצעות משתמש מהדומיין המנוהל או באמצעות התחברות ל-sqlserver.
  • אימות NTLM.
  • התחברות באמצעות כתובת IP מדומיינים שמחוברים דרך יחסי אמון.
  • מופעים עם שמות ארוכים (יותר מ-63 תווים).

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