סקירה כללית על Active Directory בניהול הלקוח (CMAD)

בדף הזה יש מידע שכדאי לעיין בו לפני שמתחילים בשילוב. אחרי שתעיינו במידע הבא, כולל המגבלות, תוכלו לעבור אל שימוש ב-Active Directory בניהול הלקוח.

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

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

לפני שמתחילים

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

  • כדי שהאימות יפעל, למופעי Cloud SQL צריכה להיות קישוריות לרשת לכל דומייני Active Directory הרלוונטיים. זה כולל את הדומיין הראשי שהמופע מצטרף אליו, וגם דומיינים מהימנים או דומיינים צאצאים שמכילים משתמשים שצריכים לגשת ל-Cloud SQL ל-SQL Server. כדי להפעיל את התכונה הזו, צריך לוודא שהיציאות הבאות (גם TCP וגם UDP) פתוחות בין מופעי Cloud SQL לבין כל בקרי הדומיין: 53,‏ 88,‏ 135,‏ 389,‏ 445,‏ 464,‏ 3268,‏ 3269 ו-49152 עד 65535.
  • צריך ליצור יחידה ארגונית (OU) כדי לאחסן את כל אובייקטי השילוב שקשורים זה לזה.
    • בתוך היחידה הארגונית הזו, צריך גם להקצות את ההרשאות הבאות לחשבון האדמין. באשף Active Directory Delegation of Control, בוחרים באפשרות:
      • יצירת אובייקטים של מחשבים
      • מחיקת אובייקטים של מחשבים
      • יצירה של אובייקטים מסוג User
      • מחיקת אובייקטים של משתמשים
      • כתיבה של כל הנכסים
      • קריאה וכתיבה של מדיניות סיסמאות ונעילות בדומיין (כולל איפוס סיסמה וקריאה וכתיבה של זמן נעילה)

      בצילום המסך הבא מוצגת דוגמה לסיכום ההרשאות באשף Active Directory Delegation of Control (מוצג ב-Windows Server 2025):

      סיכום ההרשאות של אשף ההקצאה של אמצעי בקרה ב-Active Directory

    • מומלץ גם להעניק לחשבון האדמין הזה הרשאות לניהול רשומות DNS, למשל על ידי הוספתו לקבוצה DnsAdmins.

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

      אפשרות אחרת היא להתחבר באמצעות כתובת ה-IP של המכונה, אבל יש לכך מגבלות וזה לא יעבוד לחיבורים מדומיינים מהימנים.

  • צריך לאחסן את פרטי הכניסה של האדמין בסוד של Secret Manager, בפורמט JSON הבא: 
        {
      "credentials": [
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_1",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_1"
        },
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE_2",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_2",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_2"
        }
      ]
    }

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫VALID_AFTER_UTC_VALUE_1: הערך הראשון של UTC שרוצים להשתמש בו, בפורמט YYYY-MM-DDThh:mm:ssZ. דוגמה אפשרית: 2099-07-01T10:30:00Z.
    • ‫ADMINISTRATOR_LOGIN_VALUE_1: שם הכניסה הראשון של האדמין שרוצים להשתמש בו, כמו myadmin. אסור לכלול את שם הדומיין בערך. אין תמיכה ברשומות שדומות ל-myadmin@my-domain-name.com.
    • ‫ADMINISTRATOR_PASSWORD_VALUE_1: סיסמת האדמין.
    • ‫VALID_AFTER_UTC_VALUE_2: הערך השני של שעון UTC שרוצים להשתמש בו, בפורמט YYYY-MM-DDThh:mm:ssZ. לדוגמה, 2099-07-01T10:30:00Z.
    • ‫ADMINISTRATOR_LOGIN_VALUE_2: פרטי הכניסה של האדמין השני שרוצים להשתמש בהם, כמו myadmin2. באופן דומה, אל תכללו את שם הדומיין בערך. אין תמיכה ברשומות שדומות ל-myadmin2@my-domain-name.com.
    • ‫ADMINISTRATOR_PASSWORD_VALUE_2: הסיסמה של האדמין השני.

    הקובץ הזה יכול להכיל כמה רשומות של פרטי כניסה כדי לצמצם בעיות שקשורות להפצה איטית או כדי להתאים לרוטציות מתוכננות מראש.

    השדה validAfterUTC הוא אופציונלי. אם הוא לא מצוין, המערכת תניח שפרטי הכניסה תמיד תקפים. מומלץ לשמור את פרטי הכניסה האלה באופן קבוע ב-Secret Manager ולהשתמש באוטומציה כדי לעדכן את הסיסמה אם מבצעים רוטציה של פרטי הכניסה.

    אפשר למחוק את הסוד אחרי יצירת המופע, אבל חשוב לדעת שפעולות עתידיות כמו שיבוט או הוספה של רפליקה לקריאה יגרמו לכך שהמופע החדש לא יצורף לדומיין.

    בנוסף, מחיקת המופע המקורי תשאיר אובייקטים יתומים, כמו חשבון המחשב, ב-CMAD.

  • יש לכם רשימה של כתובות ה-IP של שרתי ה-DNS עבור Active Directory בניהול הלקוח, שהם בדרך כלל בקרי הדומיין שלכם. מומלץ להשתמש בכתובות IP סטטיות לשרתים האלה.
  • הקצאה של חשבונות שירות לכל מוצר ולכל פרויקט.

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

כדי ליצור חשבון שירות עם ההרשאות הנדרשות, צריך לוודא את הדברים הבאים:

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

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

      --project=PROJECT_ID

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

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

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

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

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

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 

    --permissions="secretmanager.secrets.getIamPolicy,secretmanager.secrets.setIamPolicy"

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

  gcloud secrets add-iam-policy-binding ADCredentials --project="722300452883" 

    --member="serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com" 

    --role="projects/PROJECT-ID/roles/secretIamPolicyManager"

מידע נוסף זמין במאמר gcloud beta services identity create.

שיטות מומלצות לשילוב עם CMAD

כשמשלבים עם CMAD, מומלץ לבצע את השלבים הבאים.

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

כדי לפתור בעיות בהגדרת Active Directory בדומיין לפני שמשלבים אותו עם Cloud SQL, אפשר להשתמש בכלי האבחון של Active Directory בניהול הלקוח.

טופולוגיות לשילוב עם CMAD

‫Cloud SQL ל-SQL Server לא תומך בקבוצות מקומיות בדומיין. אבל יש חלופות:

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

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

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

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

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

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

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

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

מגבלות וחלופות

המגבלות הבאות חלות כשמשלבים עם CMAD:

  • לא ניתן להשתמש ב-Private Service Connect ‏(PSC) לקישוריות פרטית במכונות Cloud SQL for SQL Server. במקום זאת, צריך להשתמש בגישה לשירותים פרטיים (PSA).
  • אין תמיכה בקבוצות מקומיות בדומיין, אבל אפשר להוסיף קבוצות גלובליות או פרטי התחברות של משתמשים ישירות ב-SQL Server. אפשר גם להשתמש בקבוצות אוניברסליות אם כל הקבוצות והמשתמשים שייכים לאותו יער.
  • אם יש דומיינים נוספים מהימנים ואתם מתכננים לגשת למכונות של SQL Server עם שמות משתמשים משם, צריך לחבר אותם באמצעות אמון דו-כיווני. אין תמיכה בנאמנויות חד-כיווניות ובנאמנויות חיצוניות.
  • באופן כללי, למשתמשים חדשים שנוצרו דרך המסוף Google Cloud מוקצה התפקיד CustomerDbRootRole, שכולל את תפקיד מסד הנתונים הקבוע של SQL Server Agent: SQLAgentUserRole. עם זאת, אי אפשר להעניק את התפקיד הזה למשתמשים שנוצרו ישירות דרך SQL Server, כמו משתמשי CMAD, או להשתמש ב-SQL Server Agent, כי מסד הנתונים MSDB שבו צריך להעניק את התפקיד הזה מוגן.
  • שמות דומיין שמוגדרים במלואם (FQDN) לא נתמכים ב-SQL Server. לכן, כשיוצרים התחברויות ל-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 .
  • אימות Windows לא יעבוד עם אמון חיצוני. יכול להיות שהשגיאה שמוחזרת תהיה אחת מהשגיאות הבאות:
    ‫
      "The target principal name is incorrect. Cannot generate SSPI context."
    בנוסף, בהתאם להמלצות של מיקרוסופט, מומלץ להשתמש בהרשאת גישה ליער במקום בהרשאת גישה חיצונית לאימות Kerberos.
  • תמיד נעשה שימוש בגרסה העדכנית ביותר של הסוד. הסוד צריך להיות פעיל ולא ניתן להשמיד אותו.

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

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

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

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

התכונות הבאות לא נתמכות בשילוב עם CMAD:

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

מעקב

אפשר להשתמש במדד הבא כדי לעקוב אחרי הסטטוס והתקינות של CMAD:

cloudsql.googleapis.com/database/active_directory/domain_reachable

המדד הזה מדווח אם אפשר להגיע אל CMAD ממכונת Cloud SQL. זה כלי שימושי לפתרון בעיות ברשת:

cloudsql.googleapis.com/database/active_directory/instance_available

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