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

‫MySQL | PostgreSQL | SQL Server

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

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

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

צריך להפעיל את Cloud SQL Admin API.
נדרשות ההרשאות הבאות:
צריך חשבון שירות לכל מוצר ולכל פרויקט לכל פרויקט שמתכננים לשלב עם CMAD. משתמשים ב-CLI של gcloud כדי ליצור את החשבון ברמת הפרויקט. צריך לתת לחשבון השירות 'לכל מוצר, לכל פרויקט' את ההרשאות secretmanager.secrets.getIamPolicy ו-secretmanager.secrets.setIamPolicy לסוד שנוצר בשלב הקודם. מידע נוסף זמין במאמר בנושא הרשאות ב-Secret Manager.

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

כדי ליצור חשבון שירות באמצעות ה-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 . מדלגים על השלבים שקשורים לשירות מנוהל ל-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:

לא ניתן להשתמש ב-Cloud SQL ל-SQL Server במופעים שמשתמשים ב-Private Service Connect ‏(PSC) לקישוריות פרטית. במקום זאת, צריך להשתמש בגישה לשירותים פרטיים (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