סקירה כללית על 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) כדי לאחסן את כל אובייקטי השילוב שקשורים זה לזה.
    • בתוך היחידה הארגונית הזו, צריך גם להקצות את ההרשאות הבאות לחשבון האדמין:
      • ניהול אובייקטים של מחשבים (יצירת אובייקט, מחיקת אובייקט, שינוי מאפייני אובייקט)
      • ניהול אובייקטים של משתמשים (יצירת אובייקט, מחיקת אובייקט, שינוי מאפייני אובייקט)
    • מומלץ גם להעניק לחשבון האדמין הזה הרשאות לניהול רשומות 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 כדי לפתור בעיות בהגדרת AD בדומיין המקומי ובמופעים של Cloud SQL ל-SQL Server ב Google Cloud מסוף. מדלגים על השלבים שקשורים ל-Managed Service for Microsoft 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 , שכולל את תפקיד מסד הנתונים הקבוע של SQL Server Agent: SQLAgentUserRole.CustomerDbRootRole עם זאת, אי אפשר להעניק את התפקיד הזה למשתמשים שנוצרו ישירות דרך 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

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