סקירה כללית של שירות מנוהל ל-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 CustomerDbRootRole, שכולל את תפקיד מסד הנתונים הקבוע של SQL Server Agent: SQLAgentUserRole. עם זאת, אי אפשר להעניק את התפקיד הזה למשתמשים שנוצרו ישירות דרך 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 תווים).

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