סוגי קבוצות

בס"ד

קבוצות

דבר ידוע הוא שכאשר נרצה לתת אישור למשתמש מסוים להיכנס לקובץ כלשהו, נלך אל ה-Security Tab של אותו הקובץ ונוסיף שם את המשתמש. אבל מה נעשה כשנרצה לתת אישורים למאה משתמשים? כדי לפתור את הבעיה הטכנית הזאת קיימים אובייקטים שנקראים קבוצות. המטרה של קבוצה היא להכיל מספר רב של משתמשים, כדי שכאשר ניתן אישור לקבוצה, האישור יחול למעשה על כל המשתמשים של הקבוצה. ישנו סוג מסוים של קבוצות שנועדו למטרה אחרת, והן נקראות: Distribution Group. הסוג הנ"ל לא נועד לטובת מתן הרשאות, אלא כדי לשלוח מייל לכמות גדולה של נמענים במכה אחת. אנו נתעסק בשיעור הזה בסוג הקבוצות שכן אפשר להשתמש בהן לטובת מתן הרשאות. קבוצה שכזאת נקראת Security Groups.

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

וניתן דוגמא. נניח יש לנו בתוך ה-Forest את הדומיין: Google.com ואת תת הדומיין שלו: dev.google.com. עכשיו נשאל: אם אני אפתח קובץ בדומיין: Google.com – אני אוכל לרשום ב-Security Tab שלו משתמשים מתת הדומיין: dev.google.com? המציאות היא שיש קבוצות שמאפשרות זאת ויש קבוצות שלא.

כדי להבהיר את הדבר נדמיין לרגע שיש לנו בעולם פנס מיוחד שנקרא Scope והפנס הזה נמכר בשני דגמים. יש דגם שנקרא: Domain Local ובדגם הזה האור שלו חלק יחסית, ויש דגם שנקרא: Global ושם האור שלו חזק. אבל הפנס הזה לא נמכר לאנשים, הוא נמכר לקבוצות, וכל קבוצה חייבת שיהיה לה פנס שכזה. אם הפנס (ה-Scope) של הקבוצה מאיר באור חלש (דגם Domain Local), אז לא "יראו" את הקבוצה מדומיינים אחרים, ולכן לא נוכל להוסיף אותה ל-Security Tab של קבצים שם. הרי פשוט לא "רואים" אותה משם. אבל אם לקבוצה יש Global Scope אז רואים אותה גם רואים ואפשר לצרף אותה ל-Security Tab של קבצים בדומיינים אחרים.

השם של הקבוצה נקבע על פי ה-Scope שלה. למשל, קבוצה עם Scope של Domain Local (אור חלש), תיקרא: Domain Local Group, או בקיצור: DL. קבוצה עם Scope של Global תיקרא: Global Scope, או בקיצור: G. נסכם:

1. Domain Local Group נראית רק התוך הדומיין בו היא נמצאת. בשביל דומיינים אחרים היא בלתי נראית לחלוטין. ולכן, לא ניתן לרשום אותה בשום פנים ואופן ב-Security Tab של קבצים שממוקמים בדומיינים אחרים.


2. Global Group כן נראית בדומיינים אחרים, ולכן ניתן לרשום אותה בהחלט ב-Security Tab של קבצים שממוקמים בדומיינים אחרים.

אבל האם המשתמשים החברים בקבוצה יכולים להיות מדומיינים אחרים? כרגע ניתן תשובה טכנית למדיי ובהמשך חתברר ההגיון שבה. נניח שגם החברים שבקבוצה מיוצגים על ידי פנס בשם Members, כאשר גם כאן כל קבוצה מחוייבת לקבל פנס שכזה. הדבר המעניין הוא שהפנס הזה הוא הפוך לגמרי בכוונה מהפנס Scope. למשל, אם ה-Scope הוא: Domain Local, אז הפנס של Members הוא דווקא Global. זאת אומרת ניתן יהיה לצרף חברים לקבוצה מדומיינים אחרים. אבל אם הפנס של ה-Scope הוא: Global, אז הפנס של Members הוא דווקא Domain Local. זאת אומרת, לא ניתן יהיה לצרף לקבוצה חברים מדומיינים אחרים.

נשים לב שיש Scope שלישי ומיוחד שנקרא Universal. ב-Scope הזה מתנהג כמו Global Scope, אבל החידוש הוא שניתן לצרף אליו חברים גם מדומיינים אחרים. קבוצה שכזאת תיקרא בקיצור: U Group.

נסכם בטבלה את כל המידע עד כאן:

כאשר ניצור קבוצה חדשה נוכל לקבוע מהו ה-Scope שלה. כמו-כן, נוכל לקבוע האם מדובר ב-Distribution Group או ב-Security Group. להזכירכם, אנו עוסקים כאן ב-Security Groups.

קבוצות בתוך קבוצות:

ניתן בקלות לשים קבוצה בתוך קבוצה, ובפרט שהיא לא תחרוג מכלל ה"אגודל". מהו כלל ה"אגודל"? הוא נראה כך: A -> G -> U -> DL. האות A היא בעבור המשתמשים עצמם (Accounts). הכלל הוא פשוט: תעשו מה שתרצו, רק אל תשברו את האגודל. למשל, משתמשים יכולים להיות בתוך G Group. משתמשים גם יכולים להיות בתוך U Group. אמנם יש כאן "קפיצה" ברצף אבל זה בכיוון של האגודל, אז זה בסדר. קבוצה G יכולה להיות בתוך קבוצה DL, אבל קבוצה DL לא יכולה להיות בתוך קבוצה G. הבנתם את הרעיון? כמו-כן, קבוצה יכולה להיות בתוך קבוצה נוספת מאותו ה-Scope, למשל אין בעיה לקבוצה DL להיות בתוך קבוצה DL וכו'.

ניתן לשנות את ה-Scope של הקבוצה גם לאחר שיצרנו אותה, רק שיש לשים לב לשתי הגבלות:

הגבלה טכנית קטנה – העברת ה-Scope צריכה להיות ללא קפיצה. זאת אומרת, כדי להפוך G Group ל-DL Group יש להפוך את הקבוצה בשלב ביניים ל-U Group ולהיפך.

יש לשים לב שאם כבר קיימות קבוצות בתוך קבוצות, אסור שיישבר האגודל!

אסטרטגיות קבוצות:

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

A -> G <- P

אנו כבר יודעים שהאות "A" מסמלת את המשתמשים (Accounts), והאות "G" מסמלת Global Group. אבל מה מסמלת האות "P"? האות "P" מייצגת את ההרשאות עצמן.

להלן דוגמא לשימוש באסטרטגיה הנ"ל: כל עובדי המכירות יימצאו ב - Global Group בשם sales: וכשנרצה לתת לקבוצת sales הרשאות לקובץ מסויים, פשוט ניגש אליו ונוסיף את קבוצת Sales ב-Security Tab.

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

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

A -> G -> DL <- P

באסטרטגיה הנ"ל הקבוצות הגלובליות יימצאו בתוך קבוצות עם Scope של Domain Local. לשם מה צריך אסטרטגיה שכזאת?

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

הרעין הוא כדלקמן. נניח ואנחנו רוצים לאסוף את אנשי המכירות מכל הדומיינים ולתת להם גישה לקובץ שנמצא בדומיין מסויים. מה נעשה? הרעין הוא שקבוצה גלובאלית "תאסוף" את המשתמשים מכל דומיין ודומיין - ואת כל הקבוצות הגלובאליות נכניס לתוך קבוצת DL שממוקמת באותו הדומיין בו נמצא הקובץ המדובר.

ניתן את ההרשאות לקבוצת ה-DL, וכך השגנו מציאות שבה כל משתמשי המכירות מהארגון מקבלים גישה לקובץ.

A -> G -> U -> DL <- P

באסטרטגיה הנ"ל הקבוצות הגלובאליות יוכנסו לתוך קבוצות אוניברסאליות. הקבוצות האוניברסאליות יוכנסו לתוך קבוצות DL. ההרשאות יינתנו לקבוצת ה-DL.

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

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

שימו לב לרעיון המבריק הזה! כשם שכדי לתת הרשאה בבת אחת להרבה משתמשים יצרנו קבוצה - כך כשיש הרבה קבוצות וצריך לתת הרשאה לכולן אנו ניצור U Group ונשים את ה - Global Groups בתוכה.

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

כמו-כן, מטעמי אבטחה (וזה יוזכר בשיעורים הבאים), נוטים כמעט לשים את כל ה-U Groups (אם יש) ב-Forest Root.