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

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

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

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

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

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

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

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

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

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

אם הייתה תמיכה בקבוצות מקומיות של דומיינים, אפשר היה להוסיף חשבונות משתמשים פרטיים וקבוצות גלובליות ואוניברסליות כצאצאים של קבוצה מקומית של דומיינים (שמגנה על הגישה ל-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 שבו צריך להקצות את התפקיד הזה מוגן.
  • פעולות מוגבלות מסוימות עלולות לגרום לשגיאה הבאה: "Could not obtain information about Windows NT group/user". דוגמה אחת לפעולה מוגבלת מהסוג הזה היא יצירת פרטי כניסה על ידי משתמשים מדומיינים שמחוברים באמצעות קשר אמון. דוגמה נוספת היא הענקת הרשאות למשתמשים מדומיינים שמחוברים דרך קשר אמון. במקרים כאלה, בדרך כלל אפשר לנסות שוב את הפעולה והיא תצליח. אם הניסיון החוזר נכשל, סוגרים את החיבור ופותחים חיבור חדש.
  • שמות דומיין שמוגדרים במלואם (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.
  • אי אפשר לנהל ממסוף Google Cloud את פרטי ההתחברות ל-SQL Server שמבוססים על משתמשים וקבוצות ב-Active Directory.
  • ב-Cloud SQL, אם מכונה של SQL Server נוצרה ב-12 במרץ 2021 או לפני כן, אי אפשר לשלב אותה עם שירות מנוהל ל-Microsoft AD.
  • אימות של Windows לא יעבוד עם יחסי אמון חיצוניים. השגיאה יכולה להיות: "The target principal name is incorrect.‎ Cannot generate SSPI context." בנוסף, בהתאם להמלצות של מיקרוסופט, השתמשו ביחסי אמון של יער במקום ביחסי אמון חיצוניים לאימות Kerberos.

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

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

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

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

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

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

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