מבוא ל- Operations Masters

הקדמה

מאמר זה מציג את ה- Flexible Single Master Operations Roles או בקצרה FSMO Roles, אשר מוכרים בסביבת Active Directory כ- Operations Masters. במהלך המאמר מטעמי נוחות אתייחס ל- Operations Masters כ- FSMO Roles.

מהם ה- FSMO Roles?

ה- FSMO Roles הינם חמשת תפקידים שניתן לשייך ל- Domain Controllers (או DC בקצרה) ברמות שונות: הן ברמת ה- Forest והן ברמת ה- Domain.

Roles ברמת ה- Forest

קיים שרת יחיד שאוחז (מהמילה Holder) ב- Roles הנ"ל בכל ה- Forest, כאשר אין חשיבות למספר ה- Trees וה- Domains שב- Forest. שני ה- Roles אשר פועלים ברמת ה- Forest הם:

Schema Master

ה- Schema Master Role הוא ה- DC היחידי ב- Forest אשר יכול לבצע שינויים דוגמת כתיבה במקביל ל- Schema.

Domain Naming Master

ה- Domain Naming Master Role הוא ה- DC היחידי ב- Forest אשר עוקב אחר כל שמות ה- Domains ב- Forest ואחראי על הוספה והסרה של Domains ב- Forest. ה- DC אשר מאחסן את ה- Domain Naming Master הוא היחידי ב- Forest אשר יכול להוסיף ולהסיר Domains.

Roles ברמת ה- Domain

קיימים שלושה תפקידים אשר פועלים ברמת ה- Domain:

PDC Emulator
RID Master
Infrastructure Master

PDC Emulator Master

ה- PDC Emulator הוא התפקיד החשוב ביותר מכלל ה- FSMO Roles, הוא אחראי על מספר תחומים אשר יפורטו לעיל:

Primary Domain Controller עבור Windows NT 4 Domains – ה- PDC (ראשי תיבות של Primary Domain Controller) הוא DC בעל הרשאות כתיבה\קריאה ל- Directory; ה- PDC Emulator ממלא תפקיד זה ב- Windows NT 4 Domains (ומטה) בהם נמצאים BDCs (ראשי תיבות של Backup Domain Controllers, אשר הינם DCs עם הרשאות קריאה בלבד) ומאפשר ל- BDCs לגשת בצורה שקופה לשרת אשר אוחז בתפקיד ה- PDC Emulator ולעבוד במקביל אליו באופן בו עובדים עם NT4 PDCs.
Password Authority – ה- PDC Emulator מתפקד גם כ- Password Authority; כאשר משתמש, לדוגמה, מבצע Logon במקביל ל- DC מסוים ומשנה סיסמא, ה- PDC Emulator מקבל עדכון מן ה- DC שבו הוחלפה הסיסמא עם הסיסמא החדשה. במידה וה- DC שהמשתמש ביצע Logon במקביל אליו ירד, לצורכי תחזוקה\שדרוג לדוגמה, המשתמש יבצע Logon במקביל ל- DC אחר (חדש). ה- DC החדש אשר אינו מודע לשינוי הסיסמא פונה אל ה- PDC Emulator בבקשה לוודא כי הסיסמא עדכנית ולאחר מכן יאפשר Logon למשתמש. הדבר נכון גם לגבי התהליך אשר מתבצע בעת ביצוע Enable/Disable/Lock למשתמשים.
בעלות על ה- GPOs – ה- PDC Emulator הוא ה- DC היחידי אשר מורשה לצור ולערוך GPOs, יצירה ועריכה של GPOs נעשית כברירת מחדל במקביל לשיתוף ה- SYSVOL של ה- PDC Emulator. למעט במידה וה- Administrator הגדיר אחרת; חשוב לציין כי השינוי אינו מחוייב להעשות בו.
סינכרון זמן – ה- PDC Emulator אחראי על סינכרון זמן בין כלל ה- DCs לזמן אשר מוצג ב- PDC Emulator.

RID Master

ה- RID Master, ראשי תיבות של Relative ID, אחראי על הקצאת מאגרי SIDs (ראשי תיבות של Security Identifiers, מזהה אבטחה ייחודי לאובייקטים אשר נוצר בעת יצירת האובייקט) עבור DCs. מאגרים אלו מכונים Pools, והם מוקצים בתצורה של בלוק אשר מנפק 500 SIDs עבור DC מסוים.

במידה והינכם מעוניינים לצפות ב- SID של המשתמש שלכם, קיימות מספר דרכים להצגת ה- SID אחת מהן היא לגשת ל- Command Prompt ממנו הקלידו את הפקודה whoami /user. התוצאה שתקבלו תהא שוות ערך לתוצאה שבתמונה.

בתמונה ניתן לצפות ב- SID של ה- Administrator, SID מורכב בצורה הבאה:

תחילית – כל SID במערכות תוצרת מיקרוסופט מתחיל במזהה S-1-5-21
מזהה Domain ייחודי – זהו ערך ייחודי אך ורק ל- Domain שברשותכם, בדוגמה הנ"ל הערך מתחיל ב- 2942638132 ונגמר ב- 3580841348
סיומת – מזהה ייחודי לאובייקט, זהו למעשה ה- Relative ID, המזהה הנ"ל מונפק מהבלוק של ה- SIDs שהוקצאו עבור ה- DC, במקרה הנ"ל מדובר ב- Administrator שכברירת מחדל במערכות מיקרוסופט הסיומת שלו מזוהה כ- 500

במידה והינכם מעוניינים לקבל מידע נוסף אודות ה- RID Master, ב- Command Prompt, הקלידו את הפקודה DCDiag /test:RIDManager /v, את פלט הפקודה ניתן לראות בתמונה הנ"ל.

ניתן לראות כי ה- RID Master הוא השרת בשם tlv-dc-01.ben-shushan.local.

ה- Pool עבור השרת הוא מ- 1100 ל- 1599, כלומר ניתן לנצל 499 מזהים ייחודיים מתוך ה- 500 אשר הוקצו.

הסיומת הבאה עבור האובייקט הבא שיווצר תהא 1132 (מכיוון ש- rIDNextRID מורה על 1131), במידה וברצוננו לוודא זאת נוכל לצור אובייקט, לדוגמה משתמש, ולוודא זאת עבורו ב- Session שנפתח עם ההרשאות של המשתמש באמצעות פקודת ה- whoami שהוזכרה למעלה.

אפשרות נוספת, היא לגשת ל- ADSIEdit (יש לגשת ל- Start, לבחור ב- Run, ולהקליד ADSIEdit.msc) ולנווט אל ה- OU שבו יצרנו את האובייקט. כאשר נצפה במאפייני האובייקט (Properties) נוכל לראות את הערך objectSid אשר יסתיים ב- 1132 (ראה תמונה).

Infrastructure Master

ה- Infrastructure Master הוא ה- DC ב- Domain אשר אחראי על ניהול ועדכון נושא הקישור בין אובייקטים של קבוצות ומשתמשים לדוגמה בין Domains שונים.

בדוגמה שלפנינו מוצגים שני Domains: האחד ben-shushan.net (על שם האתר שלי) והשני shadowall.net (אשר שייך ליובל סיני).

ה- Domains הנפרדים עובדים ב- 2-way trust ושניהם באותו ה- Forest.

יובל סיני, אשר שייך ל- shadowall.net חבר בקבוצה Architects אשר נמצאת ב- ben-shushan.net.

ואילו נתנאל בן-שושן אשר שייך ל- ben-shushan.net חבר בקבוצה Consultants אשר קיימת ב- shadowall.net.

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

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

מיקומו של ה- Infrastructure Master חשוב במידה ואנו עושים שימוש ביותר מ- DC אחד בארגון. חשוב לציין כי במידה ועובדים עם Domain יחידי ב- Forest חשיבות מיקומו וזמינותו של ה- Infrastructure Master אינה קריטית. הדבר נכון גם למצב בו כלל שרתי ה- DC ב- Domain הם גם GC.

לצורך הבנת חשיבות מיקומו של ה- Infrastructure Master ב- Forest עם יותר מ- Domain אחד לפחות נעיין בתרחיש הבא.

בתרחיש זה ניתן לראות כי ב- ben-shushan.net ה- DC שאוחז בתפקיד ה- Infrastructure איננו Global Catalog (או בקצרה GC). לעומת זאת, ב- shadowall.net המצב הפוך – ה- DC שאוחז ב- Infrastructure Role הוא GC.

חשוב לציין כי מצב בו ה- Infrastructure Role יושב על DC שהוא גם GC אינו מומלץ (אלא כלל ה- DCs ב- Domain מתפקדים גם כ- GCs). במקרה שכזה, אם לדוגמה נבצע שינוי לאובייקט שלי, לדוגמה שינוי השם מ- Netanel Ben-Shushan ל- Nati Ben-Shushan.

במקרה שכזה, ב- ben-shushan.net השינוי יתבצע בהצלחה בכלל ה- DCs משום שהאובייקט שייך ל- Domain הנ"ל. ב- shadowall.net לעומת זאת, השינוי רק יחול על ה- DC שמתפקד כ- GC. כך שה- DC הנוסף ב- shadowall.net לא יהא מודע לשינוי (Netanel ל- Nati) בקבוצה Consultants, חשוב לציין כי ה- SID של האובייקט הוא אותו SID אך השם שונה בין ה- DCs השונים שב- shadowall.net.

הסיבה לכך טמונה בצורת העבודה של ה- Infrastructure Roles: ה- DC שאוחז בתפקיד ה- Infrastructure יפנה אל ה- GC אשר נמצא על אותו DC ויבקש להתעדכן מולו באשר לשינויים. ה- GC שעודכן אודות השינוי ושינה את הערך מ- Netanel ל- Nati מסומן כמעודכן ומדווח על כך שהוא (ה- GC) עדכני ולכן ה- Infrastructure אינו רואה צורך בבצוע עדכונים מסוימים משום שה- NTDS.DIT של ה- DC שהוא נמצא עליו מסומן מבחינתו כעדכני. במקרה שכזה ה- DC שאינו GC ב- shadowall.net לא יזכה לקבלת העדכון והערך של הקבוצה של Consultants באותו DC יצביע על Netanel. בכדי לטפל במצב ניתן להפוך את ה- DC השני ל- GC או לצורך העניין להעביר את תפקיד ה- GC מה- DC שאוחז ב- Infrastructure Role ל- DC השני.

מידע נוסף אודות מיקום ה- FSMO Roles ב- Domain ניתן למצוא ב- KB של מיקרוסופט.

איתור ה- DCs שאוחזים בתפקידי ה- FSMO

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

דרך ה- Command line באמצעות פקודות DCDiag ו- Netdom
דרך ה- MMC Snap-ins

שימוש ב- DCDiag וב- Netdom

ניתן להריץ את הפקודה DCDiag /v /test:KnowsOfRoleHolders משורת הפקודה (Command Prompt). פלט הפקודה יכיל את הטקסט הבא:

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

כמו כן, ניתן לעשות שימוש בפקודת Netdom /query FSMO לקבלת פלט מסודר של ה- FSMO Roles.

שימוש ב- MMC Snap-ins

אפשרות נוספת היא לפעול לפי הצעדים הבאים:

גש ל- Start, בחר ב- Run והקלד regsvr32 schmmgmt.dll ולחץ OK.
גש ל- Start, בחר ב- Run והקלד mmc ולחץ OK.
בחלון ה- MMC הריק שיפתח בפנייך לחץ על File ובחר ב- Add/Remove Snap-in
הוסף את Active Directory Users and Computers, Active Directory Domains and Trusts ו- Active Directory Schema אל ה- Selected snap-ins ולחץ OK.
ב- MMC שיצרת הרחב את כלל ה- snap-ins ע"י לחיצה על כפתור ה +.

על מנת לראות את ה- DC שאוחז ב- Domain Naming לחץ על מקש עכבר ימני על Active Directory Domains and Trusts ובחר ב- Operations Master.

וניתן לראות כי ה- DC שאוחז בתפקיד זה הוא tlv-dc-01.

על מנת לראות את ה- DC שאוחז ב- Schema Master לחץ על מקש עכבר ימני על Active Directory Schema ובחר ב- Operations Master.

וניתן לראות כי ה- DC שאוחז בתפקיד זה הוא tlv-dc-01.

על מנת לראות את ה- DCs שאוחזים ב- PDC Emulator/RID Master/Infrastructure הרחב את Active Directory Users and Computers ולחץ על מקש עכבר ימני על שם ה- Domain ובחר ב- Operations Masters.