איחוד של Google Cloud עם Active Directory

Last reviewed 2024-06-26 UTC

במאמר הזה מוסבר איך להגדיר את Cloud Identity או Google Workspace כדי להשתמש ב-Active Directory כספק זהויות (IdP) ומקור סמכותי.

במסמך מוצג השוואה בין המבנה הלוגי של Active Directory לבין המבנה שבו משתמשים ב-Cloud Identity וב-Google Workspace, ומוסבר איך אפשר למפות יערות, דומיינים, משתמשים וקבוצות של Active Directory. במסמך יש גם תרשים זרימה שיעזור לכם לקבוע את הגישה הכי מתאימה למיפוי בתרחיש שלכם.

במסמך הזה אנחנו יוצאים מנקודת הנחה שאתם מכירים את Active Directory.

הטמעת פדרציה

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

איחוד של Active Directory עם Cloud Identity.

הגדרת איחוד בין Active Directory לבין Cloud Identity או Google Workspace כוללת שני חלקים:

  • הקצאת משתמשים: משתמשים וקבוצות רלוונטיים מסונכרנים מעת לעת מ-Active Directory אל Cloud Identity או אל Google Workspace. התהליך הזה מבטיח שכאשר יוצרים משתמש חדש ב-Active Directory, אפשר יהיה להפנות אליו ב- Google Cloud גם לפני Google Cloud שהמשתמש המשויך נכנס לחשבון בפעם הראשונה. התהליך הזה גם מוודא שמחיקות של משתמשים מועברות.

    הקצאת ההרשאות פועלת בכיוון אחד, כלומר שינויים ב-Active Directory משוכפלים אל Google Cloud אבל לא בכיוון ההפוך. בנוסף, הקצאת ההרשאות לא כוללת סיסמאות. בהגדרה מאוחדת, Active Directory נשארת המערכת היחידה שמנהלת את פרטי הכניסה האלה.

  • כניסה יחידה (SSO): בכל פעם שמשתמש צריך לבצע אימות, Google Cloud האימות מועבר ל-Active Directory באמצעות פרוטוקול Security Assertion Markup Language ‏(SAML). ההרשאה הזו מבטיחה שרק Active Directory ינהל את פרטי הכניסה של המשתמשים, ושהמדיניות הרלוונטית או מנגנוני האימות הרב-שלבי (MFA) ייאכפו. עם זאת, כדי שהכניסה תצליח, צריך להקצות את המשתמש הרלוונטי מראש.

כדי להטמיע איחוד, אפשר להשתמש בכלים הבאים:

  • ‫Google Cloud Directory Sync ‏ (GCDS) הוא כלי חינמי ש-Google מספקת, שמבצע את תהליך הסנכרון. ‫GCDS מתקשר עם Google Cloud באמצעות Secure Sockets Layer ‏ (SSL) ובדרך כלל פועל בסביבת המחשוב הקיימת.
  • ‫Active Directory Federation Services ‏ (AD FS) מסופק על ידי מיקרוסופט כחלק מ-Windows Server. עם AD FS, אפשר להשתמש ב-Active Directory לאימות מאוחד. בדרך כלל, AD FS פועל בסביבת המחשוב הקיימת.

מכיוון שממשקי ה-API של Google Cloud זמינים לציבור ו-SAML הוא תקן פתוח, יש הרבה כלים שזמינים להטמעה של איחוד. במאמר הזה אנחנו מתמקדים בשימוש ב-GCDS וב-AD FS.

המבנה הלוגי של Active Directory

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

תשתית Active Directory.

דומיינים של Active Directory הם מאגרי משאבים לניהול, והם נחשבים לגבולות אדמיניסטרטיביים. שימוש בכמה דומיינים ביער הוא דרך אחת לפשט את הניהול או לאכוף מבנה נוסף, אבל דומיינים ביער לא מייצגים גבולות אבטחה.

המבנה הלוגי של Google Cloud

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

ב-Active Directory, המשתמשים נחשבים למשאבים, ולכן ניהול המשתמשים והאימות שלהם קשורים לדומיינים. לעומת זאת, Google Cloud לא מנהל משתמשים בארגון, למעט חשבונות שירות. במקום זאת, Google Cloud מסתמך על Cloud Identity או על Google Workspace לניהול משתמשים.

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

מבנה לוגי של Google Cloud.

כשיוצרים חשבון Cloud Identity או Google Workspace, נוצר עבורכם ארגון באופן אוטומטי. Google Cloud לחשבון Cloud Identity או Google Workspace ולארגון שמשויך אליו יש את אותו שם, והם קשורים זה לזה. Google Cloud עם זאת, ארגון יכול להפנות למשתמשים ולקבוצות מחשבונות אחרים של Cloud Identity או Google Workspace. Google Cloud

שילוב של Active Directory ו- Google Cloud

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

  • איך ממפים דומיינים ויערות לחשבונות Cloud Identity או Google Workspace
  • איך ממפים דומיינים של DNS
  • איך ממפים משתמשים
  • איך ממפים קבוצות

בקטעים הבאים נבחן כל אחד מהגורמים האלה.

מיפוי יערות

בארגונים גדולים במיוחד, לרוב משתמשים ביותר מדומיין אחד של Active Directory כדי לנהל זהויות וגישה בכל הארגון. כשמתכננים לאחד בין Active Directory ו- Google Cloud, הגורם הראשון שצריך לבדוק הוא הטופולוגיה של תשתית Active Directory.

יער יחיד, דומיין יחיד

יער יחיד, דומיין יחיד.

אם יער כולל רק דומיין אחד, אפשר למפות את כל היער של Active Directory לחשבון יחיד ב-Cloud Identity או ב-Google Workspace. החשבון הזה מספק את הבסיס לארגון יחיד שבאמצעותו אפשר לנהל את המשאבים. Google Cloud Google Cloud

בסביבה של דומיין יחיד, בקרי הדומיין ושרתי הקטלוג הגלובלי מספקים גישה לכל האובייקטים שמנוהלים ב-Active Directory. ברוב המקרים, אפשר להריץ מופע יחיד של GCDS כדי לסנכרן חשבונות משתמשים וקבוצות עם Google Cloud, וכדי לתחזק מופע יחיד או צי של AD FS לטיפול בכניסה יחידה.

יער יחיד, דומיינים מרובים

יער יחיד, מספר דומיינים.

אם יער מכיל כמה דומיינים של Active Directory, אפשר לארגן אותם בעץ דומיינים אחד או יותר. בשני המקרים, אפשר למפות את כל היער לחשבון יחיד ב-Cloud Identity או ב-Google Workspace. החשבון הזה ישמש כבסיס לארגון Google Cloud יחיד שתוכלו להשתמש בו כדי לנהל את Google Cloud המשאבים שלכם.

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

בהתאם לאופן שבו אתם מתכננים למפות קבוצות, כדי לבצע איחוד של יער עם כמה דומיינים באמצעותGoogle Cloud נדרשים מופע אחד או יותר של GCDS, אבל רק מופע אחד או Fleet של AD FS כדי לטפל בכניסה יחידה.

יערות מרובים עם יחסי אמון בין היערות

יערות מרובים עם יחסי אמון בין היערות.

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

אם לכל היערות יש יחסי אמון דו-כיווניים עם יער אחר, אפשר למפות את כל הסביבה לחשבון יחיד ב-Cloud Identity או ב-Google Workspace. החשבון הזה מספק את הבסיס לארגון יחיד שלGoogle Cloud Google Cloud שבו אפשר לנהל את המשאבים. Google Cloud

למרות ששרתי קטלוג גלובלי מספקים גישה לנתונים מדומיינים מרובים, ההיקף שלהם מוגבל ליער יחיד. לכן, בסביבה מרובת יערות, צריך לשלוח שאילתות לכמה בקרי דומיין או שרתי קטלוג גלובלי כדי לקבל, לדוגמה, רשימה מלאה של משתמשים. כתוצאה מהמגבלה הזו, כדי לבצע פדרציה של סביבה עם כמה יערות באמצעות Google Cloud צריך לפחות מופע אחד של GCDS לכל יער. יחסי אמון בין יערות מאפשרים אימות משתמשים שפועל מעבר לגבולות היער, כך שמופע יחיד או צי של AD FS מספיקים לטיפול בכניסה יחידה.

אם הסביבה שלכם משתרעת על פני כמה יערות ללא אמון בין היערות, אבל כל הדומיינים של Active Directory שרלוונטיים לאיחוד עם Google Cloudמחוברים באמצעות אמון חיצוני, אז אותם שיקולים חלים.

יערות מרובים ללא יחסי אמון בין היערות

יערות מרובים ללא יחסי אמון בין היערות.

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

לכן, אי אפשר למפות כמה יערות שאין בהם יחסי אמון בין היערות לחשבון יחיד ב-Cloud Identity או ב-Google Workspace. במקום זאת, כל יער צריך להיות ממופה לחשבון נפרד ב-Cloud Identity או ב-Google Workspace, מה שמצריך הפעלה של לפחות מופע אחד של GCDS ושרת אחד או צי של שרתי AD FS לכל יער.

ב- Google Cloud, נוצרת יחידה ארגונית נפרדת לכל חשבון Cloud Identity או Google Workspace. ברוב המקרים, אין צורך לנהל כמה ארגונים נפרדים. אפשר לבחור אחד מהארגונים ולשייך אותו לחשבונות אחרים ב-Cloud Identity או ב-Google Workspace. כך יוצרים ארגון שמאוחד עם כמה יערות של Active Directory. הארגונים האחרים לא נמצאים בשימוש.

מיפוי דומיינים של DNS

ל-DNS יש תפקיד חשוב גם ב-Active Directory וגם ב-Cloud Identity וב-Google Workspace. הגורם השני שצריך לבדוק כשמתכננים לאחד את Active Directory ו- Google Cloud הוא איך לשתף או למפות דומיינים של DNS בין Active Directory לבין Google Cloud . Google Cloud

שימוש בדומיינים של DNS ב-Active Directory

ביער Active Directory, נעשה שימוש בדומיינים של DNS בכמה מקומות:

  • דומיינים של DNS ב-Active Directory: כל דומיין של Active Directory תואם לדומיין של DNS. הדומיין יכול להיות גלובלי, כמו corp.example.com, או שם דומיין מקומי כמו corp.local או corp.internal.
  • דומיינים של שרתי דואר (MX): כתובות אימייל משתמשות בדומיין DNS. במקרים מסוימים, הדומיין הזה זהה לדומיין ה-DNS של Active Directory, אבל בהרבה מקרים נעשה שימוש בדומיין אחר, שלרוב קצר יותר, כמו example.com. מומלץ שלמשתמשים ב-Active Directory תהיה כתובת האימייל שמשויכת למאפיין האופציונלי mail.
  • דומיינים של סיומות UPN: הדומיינים האלה משמשים לשמות משתמשים ראשיים (UPN). כברירת מחדל, נעשה שימוש בדומיין DNS של Active Directory של הדומיין של המשתמש כדי ליצור UPN. לכן, עבור המשתמש john בדומיין corp.example.com, שם המשתמש הראשי שמוגדר כברירת מחדל הוא john@corp.example.com. עם זאת, אפשר להגדיר יער כך שישתמש בדומיינים נוספים של DNS כסיומות של UPN שלא תואמות לדומיינים של DNS ב-Active Directory או לדומיינים של MX. שמות UPN הם אופציונליים ונשמרים בשדה userPrincipalName של המשתמש.
  • דומיינים של נקודות קצה: לשרתים שפונים לציבור, כמו שרתי AD FS, בדרך כלל מוקצה שם DNS, כמו login.external.example.com. הדומיין שמשמש למטרות האלה יכול להיות חופף לדומיין של רשומת ה-MX, הסיומת של שם המשתמש העיקרי (UPN) או דומיין ה-DNS של Active Directory, או שהוא יכול להיות דומיין שונה לחלוטין.

שימוש בדומייני DNS ב- Google Cloud

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

מערכת הכניסה לחשבון Google קובעת את הספרייה או ספק הזהויות שבהם צריך להשתמש לאימות משתמש על סמך החלק של הדומיין בכתובות האימייל, בהתאם ל@. לדוגמה, כדי לאמת כתובת אימייל שמשתמשת בדומיין gmail.com, מערכת הכניסה באמצעות חשבון Google משתמשת בספרייה של משתמשי Gmail.

שימוש בדומיינים של DNS ב- Google Cloud.

כשנרשמים לחשבון Google Workspace או Cloud Identity, יוצרים ספרייה פרטית ששירות הכניסה יכול להשתמש בה לאימות. בדיוק כמו שספריית Gmail משויכת לדומיין gmail.com, חשבונות Google Workspace ו-Cloud Identity צריכים להיות משויכים לדומיין מותאם אישית. יש שלושה סוגים שונים של דומיינים:

  • דומיין ראשי: הדומיין הזה מזהה את חשבון Cloud Identity או חשבון Google Workspace, והוא משמש כשם הארגון ב- Google Cloud. כשנרשמים ל-Cloud Identity או ל-Google Workspace, צריך לציין את שם הדומיין הזה.
  • דומיין משני: בנוסף לדומיין הראשי, אפשר לשייך לחשבון Cloud Identity או לחשבון Google Workspace דומיינים משניים אחרים. כל משתמש בספרייה משויך לדומיין הראשי או לאחד מהדומיינים המשניים. שני משתמשים, johndoe@example.com ו-johndoe@secondary.example.com, נחשבים למשתמשים נפרדים אם example.com הוא הדומיין הראשי ו-secondary.example.com הוא דומיין משני.
  • דומיין חלופי: דומיין חלופי הוא שם חלופי לדומיין אחר. כלומר, johndoe@example.com ו-johndoe@alias.example.com מתייחסים לאותו משתמש אם alias.example.com מוגדר כדומיין חלופי של example.com.

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

  • הם צריכים להיות שמות דומיין תקפים של DNS גלובלי. במהלך ההגדרה, יכול להיות שתצטרכו גישת אדמין לאזורי ה-DNS המתאימים כדי לאמת את הבעלות על הדומיין.
  • דומיין, כמו example.com, יכול להתייחס רק לספרייה אחת. עם זאת, אפשר להשתמש בתת-דומיינים שונים, כמו subdomain.example.com, כדי להפנות לספריות שונות.
  • לדומיינים הראשיים והמשניים צריכה להיות רשומת MX תקינה, כדי שהודעות שנשלחות לכתובות אימייל שנוצרו באמצעות שם הדומיין הזה יוכלו להימסר בצורה תקינה.

כדי להפעיל סנכרון בין הספריות, צריך לבצע מיפוי בין דומיינים של Active Directory לבין הדומיינים שבהם נעשה שימוש ב-Cloud Identity או ב-Google Workspace. המיפוי הנכון תלוי באופן השימוש ב-Active Directory, ודורש בדיקה מעמיקה של האופן שבו המשתמשים מזוהים ביער Active Directory ואיך אפשר למפות אותם ל-Cloud Identity או ל-Google Workspace.

משתמשים במפה

הגורם השלישי שצריך לבדוק כשמתכננים לאחד את Active Directory עםGoogle Cloud הוא איך למפות משתמשים בין Active Directory לבין Cloud Identity או Google Workspace.

זיהוי משתמשים ב-Active Directory

מערכת Active Directory משתמשת באופן פנימי בשני מזהים כדי לזהות משתמשים באופן ייחודי:

  • ‫objectGUID: המזהה הייחודי הזה נוצר כשמשתמש נוצר, והוא לא משתנה אף פעם.
  • ‫objectSID: ה-SID, או מזהה האבטחה, משמש לכל בדיקות הגישה. המזהה הזה הוא ייחודי ויציב בתוך דומיין, אבל יכול להיות שכשמעבירים משתמש לדומיין אחר ביער, מוקצה לו SID חדש.

אף אחד מהמזהים האלה לא משמעותי למשתמשים, ולכן Active Directory מציע שתי דרכים ידידותיות למשתמש לזיהוי משתמשים:

  • UPN ‏ (userPrincipalName): הדרך המועדפת לזיהוי משתמש היא באמצעות UPN. שמות UPN הם בפורמט RFC 822 של כתובות אימייל, והם נוצרים משילוב של שם המשתמש עם סיומת דומיין של UPN, כמו בדוגמה johndoe@corp.example.com. למרות ש-UPN היא הדרך המועדפת לזיהוי משתמשים, היא אופציונלית, ולכן יכול להיות שלחלק מהמשתמשים ביער Active Directory אין UPN.

    מומלץ להשתמש בכתובות אימייל תקינות בתור שמות משתמש ראשיים (UPN), אבל Active Directory לא מחייב את זה.

  • שם הכניסה בגרסאות של Windows לפני Windows 2000‏ (sAMAccountName): השם הזה הוא שילוב של שם דומיין NetBIOS ושם משתמש בפורמט domain<var>user, כמו corp\johndoe. השמות האלה נחשבים מיושנים, אבל עדיין נפוץ השימוש בהם והם המזהה היחיד של משתמש שחובה לציין.

חשוב לציין שב-Active Directory לא משתמשים בכתובת האימייל של המשתמש (mail) כדי לזהות משתמשים. לכן, השדה הזה הוא לא חובה ולא צריך להיות ייחודי ביער.

אפשר לשנות את כל המזהים האלה בכל שלב.

מיפוי של זהויות משתמשים

כדי למפות משתמשים ב-Active Directory למשתמשים ב-Cloud Identity או ב-Google Workspace, צריך שני סוגי מידע לכל משתמש:

  • מזהה ייחודי ויציב שאפשר להשתמש בו במהלך הסנכרון כדי לעקוב אחרי המשתמש ב-Active Directory שמתאים למשתמש ב-Cloud Identity או ב-Google Workspace. בצד של AD, ‏ objectGUID מתאים באופן מושלם למטרה הזו.
  • כתובת אימייל שבה חלק הדומיין תואם לדומיין ראשי, משני או כינוי של חשבון Cloud Identity או Google Workspace. כתובת האימייל הזו תשמש בכל Google Cloud, לכן חשוב לוודא שהיא בעלת משמעות. אי אפשר לגזור כתובת מה-objectGUID, כמו גם מכתובות אימייל אחרות שנוצרות באופן אוטומטי.

עבור משתמש ב-Active Directory, יש שני שדות שיכולים לספק כתובת אימייל ב-Cloud Identity או ב-Google Workspace:‏ userPrincipalName ו-mail.

מיפוי לפי השם הראשי של המשתמש

כדי להשתמש בשדה userPrincipalName, צריכים להתקיים שני קריטריונים לכל המשתמשים שחלים עליהם כללי הסנכרון:

  • שמות המשתמש הראשיים (UPN) חייבים להיות כתובות אימייל חוקיות. כל הדומיינים שמשמשים כדומיינים עם סיומת UPN חייבים להיות גם דומייני MX, וצריך להגדיר אותם כך שאימייל שנשלח ל-UPN של משתמש יועבר לתיבת הדואר הנכנס שלו.

  • צריך להשלים את הקצאות ה-UPN. לכל המשתמשים שחלים עליהם כללי הסנכרון צריך להיות מוקצה UPN. הפקודה הבאה ב-PowerShell יכולה לעזור לכם למצוא משתמשים שאין להם UPN:

    Get-ADUser -LDAPFilter "(!userPrincipalName=*)"

אם שני הקריטריונים האלה מתקיימים, אפשר למפות בבטחה שמות משתמשים ראשיים לכתובות אימייל ב-Cloud Identity או ב-Google Workspace. אפשר להשתמש באחד מהדומיינים של הסיומת של שם המשתמש הראשי כדומיין הראשי ב-Cloud Identity או ב-Google Workspace, ולהוסיף את שאר הדומיינים של הסיומת של שם המשתמש הראשי כדומיינים משניים.

אם אחד מהקריטריונים לא מתקיים, עדיין אפשר למפות שמות UPN לכתובות אימייל ב-Cloud Identity או ב-Google Workspace, אבל צריך לשים לב להערות הבאות:

  • אם שמות ה-UPN לא תקינים ככתובות אימייל, יכול להיות שהמשתמשים לא יקבלו הודעות אימייל שנשלחות על ידי Google Cloud, וכתוצאה מכך יפספסו מידע חשוב.
  • המערכת מתעלמת ממשתמשים ללא UPN במהלך הסנכרון.
  • אתם יכולים להגדיר את הסנכרון כך שיחליף את הדומיין של הסיומת UPN בדומיין אחר. כשמשתמשים בכמה דומיינים של סיומת UPN ביער, הגישה הזו עלולה ליצור כפילויות, כי כל הדומיינים של סיומת UPN יוחלפו בדומיין יחיד. במקרה של כפילויות, ניתן לסנכרן רק משתמש אחד.

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

מיפוי לפי כתובת אימייל

כדי להשתמש בשדה mail, צריך לעמוד בקריטריונים הבאים לגבי כל המשתמשים שחלים עליהם כללי הסנכרון:

  • צריך להשלים את המטלות שקשורות לאימייל. צריך למלא את השדה mail לכל המשתמשים שחלים עליהם כללי הסנכרון. הפקודה הבאה ב-PowerShell יכולה לעזור לכם למצוא משתמשים שהשדה הזה לא מאוכלס עבורם:

    Get-ADUser -LDAPFilter "(!mail=*)"

  • כתובות האימייל חייבות להשתמש בקבוצה נבחרת של דומיינים, שכולם בבעלותכם. אם חלק מהמשתמשים שלכם משתמשים בכתובות אימייל שמתייחסות לחברות שותפות או לספקי אימייל לצרכנים, אי אפשר להשתמש בכתובות האימייל האלה.

  • כל כתובות האימייל צריכות להיות ייחודיות ביער. מכיוון ש-Active Directory לא אוכף ייחודיות, יכול להיות שתצטרכו להטמיע בדיקות או מדיניות בהתאמה אישית.

אם כל המשתמשים הרלוונטיים עומדים בקריטריונים האלה, אפשר לזהות את כל הדומיינים שמשמשים את כתובות האימייל האלה ולהשתמש בהם כדומיינים ראשיים ומשניים ב-Cloud Identity או ב-Google Workspace.

אם אחד מהקריטריונים לא מתקיים, עדיין אפשר למפות כתובות אימייל לכתובות אימייל ב-Cloud Identity או ב-Google Workspace, אבל יש כמה מגבלות:

  • במהלך הסנכרון, המערכת תתעלם ממשתמשים בלי כתובות אימייל, וגם ממשתמשים עם כתובות אימייל שמשתמשים בדומיינים שלא משויכים לחשבון Cloud Identity או לחשבון Google Workspace.
  • אם לשני משתמשים יש את אותה כתובת אימייל, רק משתמש אחד יסונכרן.
  • אפשר להגדיר את הסנכרון כך שהדומיין של כתובות האימייל יוחלף בדומיין אחר. במהלך התהליך הזה יכולים להיווצר כפילויות, ובמקרה כזה רק משתמש אחד יסונכרן.

מיפוי קבוצות

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

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

ב-Active Directory יש שני סוגים של קבוצות: קבוצות תפוצה וקבוצות אבטחה. קבוצות תפוצה משמשות לניהול רשימות תפוצה באימייל. סנכרון קבוצות תפוצה רלוונטי כשמבצעים העברה מ-Microsoft Exchange ל-Google Workspace, כדי ש-GCDS יוכל לטפל בקבוצות תפוצה רגילות ודינמיות. קבוצות תפוצה לא רלוונטיות לניהול זהויות והרשאות גישה ב- Google Cloud, ולכן הדיון הזה מתמקד רק בקבוצות אבטחה.

מיפוי קבוצות בין Active Directory לבין Google Cloud הוא אופציונלי. אחרי שמגדירים הקצאת הרשאות למשתמשים, אפשר ליצור קבוצות ולנהל אותן ישירות ב-Cloud Identity או ב-Google Workspace. המשמעות היא ש-Active Directory נשארת המערכת המרכזית לניהול זהויות, אבל לא לניהול גישה. כדי לשמור על Active Directory כמערכת מרכזית לניהול זהויות וניהול גישה, מומלץ לסנכרן קבוצות אבטחה מ-Active Directory במקום לנהל אותן ב-Cloud Identity או ב-Google Workspace. בגישה הזו, אפשר להגדיר את IAM כך שתוכלו להשתמש בחברויות בקבוצות ב-Active Directory כדי לקבוע למי יש גישה למשאבים מסוימים ב- Google Cloud.

קבוצות אבטחה ב-Active Directory

קבוצות אבטחה ממלאות תפקיד בסיסי באבטחת Windows ובניהול הגישה ל-Active Directory. התפקיד הזה מוקצה באמצעות שלושה סוגים שונים של קבוצות Active Directory: קבוצות מקומיות בדומיין, קבוצות גלובליות וקבוצות אוניברסליות.

קבוצות אבטחה ב-AD.

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

אם יער Active Directory מכיל רק דומיין אחד, אפשר לסנכרן את כל שלושת סוגי קבוצות האבטחה באמצעות GCDS. אם ביער Active Directory יש יותר מדומיין אחד, סוג הקבוצה קובע אם אפשר לסנכרן אותה עם Cloud Identity או עם Google Workspace, ואיך אפשר לעשות זאת.

מכיוון שקבוצות מקומיות וגלובליות בדומיין לא משוכפלות באופן מלא ביער, שרתי הקטלוג הגלובלי מכילים מידע חלקי לגביהן. ההגבלה הזו היא מכוונת ועוזרת להאיץ את השכפול של הספרייה, אבל היא מהווה מכשול כשרוצים לסנכרן קבוצות כאלה עם Cloud Identity או עם Google Workspace. במילים אחרות, אם תגדירו את GCDS כך שישתמש בשרת קטלוג גלובלי כמקור, הכלי יוכל למצוא קבוצות מכל הדומיינים ביער. אבל רק קבוצות שנמצאות באותו דומיין כמו שרת הקטלוג הגלובלי יכילו רשימת חברים ויתאימו לשכפול. כדי לסנכרן קבוצות מקומיות או גלובליות בדומיין ביער עם כמה דומיינים, צריך להפעיל מופע GCDS נפרד לכל דומיין.

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

לפני שמחליטים שצריך כמה מופעים של GCDS כדי לסנכרן כמה דומיינים של Active Directory עם Cloud Identity או Google Workspace, חשוב לזכור שלא צריך לסנכרן את כל הקבוצות. לכן, כדאי לבדוק איך משתמשים בדרך כלל בסוגים שונים של קבוצות אבטחה ביער Active Directory.

השימוש בקבוצות אבטחה ב-Active Directory

בקטעים הבאים מתוארים סוגי קבוצות האבטחה שמשמשות ב-Active Directory.

קבוצות משאבים

‫Windows משתמש במודל גישה שמבוסס על רשימות של בקרת גישה (ACL). לכל משאב, כמו קובץ או אובייקט LDAP, יש רשימת ACL משויכת שקובעת לאילו משתמשים יש גישה אליו. המשאבים ורשימות ה-ACL הם ברמת פירוט גבוהה מאוד, ולכן יש הרבה מהם. כדי לפשט את התחזוקה של רשימות ACL, נהוג ליצור קבוצות משאבים כדי לאגד משאבים שנעשה בהם שימוש לעיתים קרובות ושניגשים אליהם יחד. מוסיפים את קבוצת המשאבים לכל רשימות ה-ACL הרלוונטיות פעם אחת, ומנהלים את הגישה באמצעות שינוי החברים בקבוצת המשאבים, ולא באמצעות שינוי רשימות ה-ACL.

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

תפקידים וקבוצות בארגון

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

קבוצות תפקידים מרכזות את ההרשאות שנדרשות לתפקיד מסוים בארגון. לדוגמה, קבוצת תפקידים בשם Engineering Documentation Viewer (צפייה במסמכי הנדסה) יכולה לתת לחברים הרשאת קריאה בלבד לכל מסמכי ההנדסה. בפועל, כדי ליישם את זה, צריך ליצור קבוצת תפקידים ולהוסיף אותה כחברה בכל קבוצות המשאבים שמשמשות לשליטה בגישה לסוגים שונים של תיעוד.

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

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

בתרשים הבא מוצג דפוס קינון שמשמש בדרך כלל בסביבות Active Directory עם כמה דומיינים.

דפוס הקינון שמשמש בסביבות AD עם כמה דומיינים.

קבוצות ב-Cloud Identity וב-Google Workspace

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

בדומה למשתמשים, מערכות Cloud Identity ו-Google Workspace מזהות קבוצות לפי כתובת אימייל. כתובת האימייל לא צריכה להתאים לתיבת דואר בפועל, אבל היא צריכה להשתמש באחד מהדומיינים שרשומים בחשבון Cloud Identity הרלוונטי.

בניגוד לקבוצות ב-Active Directory, לחברים בקבוצה ב-Cloud Identity או ב-Google Workspace לא מוענקת הרשאה מרומזת להציג רשימה של חברים אחרים באותה קבוצה. במקום זאת, בדרך כלל נדרשת הרשאה מפורשת כדי לשלוח שאילתות לגבי חברות בקבוצה.

השימוש בקבוצות ב- Google Cloud

Google Cloud מודל הגישה הוא לפי תפקיד, ולא לפי רשימת בקרת גישה (ACL). התפקידים חלים על כל המשאבים מסוג מסוים שנמצאים בהיקף מסוים. לדוגמה, לתפקיד Kubernetes Engine Developer יש גישה מלאה לאובייקטים של Kubernetes API בכל האשכולות בפרויקט נתון. בגלל האופי של התפקידים, אין כמעט צורך לתחזק קבוצות משאבים ב- Google Cloud, ובדרך כלל אין צורך לסנכרן קבוצות משאבים עם Google Cloud.

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

סנכרון של תפקידים וקבוצות בארגון.

אם אתם מיישמים באופן עקבי קבוצות משאבים כקבוצות מקומיות בדומיין, וקבוצות תפקידים וקבוצות ארגוניות כקבוצות גלובליות או אוניברסליות, אתם יכולים להשתמש בסוג הקבוצה כדי לוודא שרק קבוצות תפקידים וקבוצות ארגוניות מסונכרנות.

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

מיפוי של זהויות קבוצתיות

כדי למפות קבוצות אבטחה של Active Directory לקבוצות של Cloud Identity או Google Workspace, צריך מזהה משותף. ב-Cloud Identity וב-Google Workspace, המזהה הזה צריך להיות כתובת אימייל שחלק הדומיין שלה תואם לדומיין הראשי, המשני או לכינוי הדומיין של חשבון Cloud Identity או Google Workspace. כתובת האימייל הזו תשמש לאורך כל התהליך Google Cloud, ולכן היא צריכה להיות קריאה לבני אדם. כתובת האימייל לא צריכה להיות קשורה לתיבת דואר.

ב-Active Directory, קבוצות מזוהות לפי השם הנפוץ שלהן (cn) או לפי שם הכניסה שלהן בגרסאות שלפני Windows 2000 (sAMAccountName). בדומה לחשבונות משתמשים, לקבוצות יכולה להיות גם כתובת אימייל (mail), אבל כתובות אימייל הן מאפיין אופציונלי של קבוצות, ו-Active Directory לא מאמת ייחודיות.

יש שתי אפשרויות למיפוי זהויות של קבוצות בין Active Directory לבין Cloud Identity או Google Workspace.

מיפוי לפי שם

היתרון בשימוש בשם הנפוץ (cn) הוא שהוא תמיד זמין, ולפחות בתוך יחידה ארגונית הוא ייחודי. עם זאת, השם הנפוץ הוא לא כתובת אימייל, ולכן צריך להוסיף לו סיומת @DOMAIN כדי להפוך אותו לכתובת אימייל.

אפשר להגדיר את GCDS כך שידאג באופן אוטומטי להוספת סיומת לשם הקבוצה. מכיוון ש-Active Directory מוודא שאין התנגשות בין שמות של קבוצות ושמות של משתמשים, סביר להניח שכתובת אימייל שנוצרת בדרך הזו לא תגרום להתנגשויות.

אם יער Active Directory מכיל יותר מדומיין אחד, חלים ההסברים הבאים:

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

מיפוי לפי כתובת אימייל

אם משתמשים בכתובת האימייל (mail) כדי למפות זהויות של קבוצות, צריך לעמוד באותם קריטריונים כמו כשמשתמשים בכתובת האימייל כדי למפות משתמשים:

  • צריך להשלים את המטלות שקשורות לאימייל. למרות שבדרך כלל לקבוצות תפוצה יש כתובת אימייל, לקבוצות אבטחה לרוב אין את המאפיין הזה. כדי להשתמש בכתובת האימייל למיפוי זהויות, צריך למלא את השדה mail בקבוצות אבטחה שמועברות בסנכרון. הפקודה הבאה ב-PowerShell יכולה לעזור לכם למצוא חשבונות שבהם השדה הזה לא מאוכלס:

    Get-ADGroup -LDAPFilter "(!mail=*)"

  • כתובות האימייל חייבות להשתמש בקבוצה נבחרת של דומיינים, שכולם בבעלותכם. אם חלק מהמשתמשים שלכם משתמשים בכתובות אימייל שמתייחסות לחברות שותפות או לספקי אימייל לצרכנים, לא תוכלו להשתמש בכתובות האלה.

  • כל כתובות האימייל צריכות להיות ייחודיות ביער. מכיוון ש-Active Directory לא אוכף ייחודיות, יכול להיות שתצטרכו להטמיע בדיקות או מדיניות בהתאמה אישית.

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

אם אחד מהקריטריונים לא מתקיים, עדיין אפשר למפות שמות UPN לכתובות אימייל ב-Cloud Identity או ב-Google Workspace, אבל יש כמה מגבלות:

  • המערכת תתעלם מקבוצות ללא כתובות אימייל במהלך הסנכרון, וגם מכתובות אימייל שמשתמשות בדומיינים שלא משויכים לחשבון Cloud Identity או לחשבון Google Workspace.
  • אם לשתי קבוצות יש את אותה כתובת אימייל, רק אחת מהן תסונכרן.

מיפוי קבוצות לפי כתובת אימייל לא נתמך אם יער Active Directory מכיל יותר מדומיין אחד ואתם משתמשים בהחלפת דומיין למיפוי משתמשים.

מיפוי של יחידות ארגוניות

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

ב- Google Cloud, תיקיות ופרויקטים משמשים למטרה דומה, אבל סוגי המשאבים שמנוהלים בארגון Google Cloud שונים מאוד מהמשאבים שמנוהלים ב-Active Directory. לכן, היררכיית התיקיות המתאימה Google Cloud לארגון נוטה להיות שונה באופן משמעותי מהמבנה של היחידות הארגוניות ב-Active Directory. לכן, מיפוי אוטומטי של יחידות ארגוניות לתיקיות ולפרויקטים הוא בדרך כלל לא מעשי ולא נתמך על ידי GCDS.

בנוסף לתיקיות, ב-Cloud Identity וב-Google Workspace יש תמיכה במושג של יחידות ארגוניות. יחידות ארגוניות נוצרות כדי לקבץ ולארגן משתמשים, בדומה ל-Active Directory. אבל בניגוד ל-Active Directory, הן חלות רק על משתמשים ולא על קבוצות.

GCDS מציע את האפשרות לסנכרן יחידות ארגוניות של Active Directory עם Cloud Identity או Google Workspace. במקרים שבהם Cloud Identity משמש רק להרחבת ניהול הזהויות של Active Directory אל Google Cloud, בדרך כלל אין צורך למפות יחידות ארגוניות.

בחירת המיפוי הנכון

כמו שצוין בתחילת המאמר הזה, אין דרך אחת הכי טובה למפות את המבנים של Active Directory ושל Google Cloud. כדי לעזור לכם לבחור את המיפוי הנכון לתרחיש שלכם, בתרשימי ההחלטה הבאים מסוכמים הקריטריונים שנדונו בקטעים הקודמים.

קודם כל, כדאי לעיין בתרשים הבא כדי לזהות כמה חשבונות Cloud Identity או Google Workspace, מופעי GCDS ומופעי AD FS או צי של מופעים תצטרכו.

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

אחר כך, מעיינים בתרשים השני כדי לזהות את הדומיינים שצריך להגדיר בחשבון Cloud Identity או בחשבון Google Workspace.

תרשים החלטות.

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