המדריך המלא לארכיטקטורת FSMO ב-Active Directory: מה באמת קורה מאחורי הקלעים?

אם אתם מנהלים סביבת תשתיות וזהויות, אתם יודעים ש-Active Directory (AD) פועל רוב הזמן כמו סוג של 'דמוקרטיה' מושלמת. מודל העבודה הוא Multi-Master Replication – מה שאומר שאתם יכולים ליצור משתמש, לאפס סיסמה או לשנות הרשאות כמעט מול כל שרת Domain Controller (DC) בארגון.

אבל איך הקסם הזה קורה? איך המידע מרופלק לכל שאר השרתים? מאחורי הקלעים, כל שרת מנהל מונה גרסאות פנימי שנקרא USN (Update Sequence Number). ברגע שביצעתם שינוי ב-DC מסוים, ה-USN שלו עולה, והוא שולח 'צעקה' לשאר השרתים: 'היי, יש לי מידע חדש'. שירות שנקרא KCC (Knowledge Consistency Checker) רץ ברקע ומייצר אוטומטית את מסלול התקשורת היעיל ביותר (הטופולוגיה) כדי להעביר את העדכון הזה לכל שאר השרתים ברשת.

עד כאן הכל עובד נהדר. אבל מתי הדמוקרטיה הזו קורסת? ישנן פעולות קריטיות בארגון שאם נאפשר למספר שרתים לבצע אותן בו-זמנית, ניצור התנגשויות (Conflicts) שירסקו את ה-Database. עבור הפעולות הרגישות הללו, מיקרוסופט יצרה חמישה תפקידי 'דיקטטור' – שרתים בעלי סמכות בלעדית. התפקידים האלו נקראים FSMO (Flexible Single Master Operations).

חלוקת התפקידים ברורה: שניים מהם יחידים בכל ה-Forest (רמת הארגון כולו), ושלושה מהם יחידים בכל Domain. בואו נפרק אותם למרכיבים.

תפקידי ה-Forest (אחד בכל הארגון)

1. Schema Master – ה-DNA של הארגון. תארו לעצמכם את הסכימה (Schema) כשרטוט האדריכלי או ה-DNA של ה-Active Directory. היא לא מכילה את המידע עצמו (היא לא יודעת שקיימת משתמשת בשם 'שירן'), אבל היא מכילה את החוקים והמבנה – למשל, ההגדרה שלמשתמש יכולה להיות תכונה (Attribute) של מספר טלפון או כתובת דוא"ל. ה-Schema Master הוא השרת היחיד ביער שמורשה לערוך את השרטוט הזה (למשל, כשאתם מתקינים שרת Exchange או מרחיבים סכימה).

כל כמה זמן הסכימה מרופלקת? שאלה קלאסית של אנשי תשתיות. התשובה היא שלסכימה אין תזמון עצמאי. היא Partition לכל דבר (Schema Partition) ורוכבת על גלגלי הרפליקציה הרגילים של ה-AD:

• ▸בתוך אותו סניף (Intra-site): שינוי מופץ לרוב בתוך כ-15 שניות.
• ▸בין סניפים (Inter-site): בהתאם למה שהגדרתם ב-Site Links — ברירת המחדל היא 180 דקות, למרות שבסביבות Production מודרניות מקובל להוריד זאת ל-15 דקות.

2. Domain Naming Master – ה'טאבו' של הרשת. רוצים להקים Domain חדש? או אולי להסיר אחד ישן? אתם חייבים לדבר עם ה-Domain Naming Master. התפקיד שלו הוא להיות משרד הרישום המרכזי של היער. הוא מוודא שאין כפילויות בשמות ושאף מנהל רשת בסניף אחר לא מקים בדיוק עכשיו דומיין עם שם זהה.

תפקידי ה-Domain (אחד בכל דומיין)

3. PDC Emulator (Primary Domain Controller) – הלב הפועם. אם יש תפקיד אחד שה-DC שלכם 'יזיע' בגללו, זה ה-PDC Emulator. זהו התפקיד העמוס, הקריטי והחשוב ביותר ביומיום שלכם. למה? כי הוא אחראי על:

• ▸סיסמאות בזמן אמת: הוא השרת היחיד שמחזיק גישת Read-Write לסיסמאות. כשמשתמש מחליף סיסמה ב-DC מקומי, אותו DC מיד מעדכן את ה-PDC. אם משתמש מנסה להתחבר ומקליד סיסמה שגויה, ה-DC המקומי לא ינעל אותו מיד, אלא יבדוק קודם מול ה-PDC – 'תגיד, אולי הוא בדיוק שינה סיסמה ולא הספקת לעדכן אותי?'.
• ▸סנכרון זמנים (NTP): ה-PDC הוא ה'שעון הדובר' של הדומיין. הוא מסנכרן את הזמן מול מקור חיצוני, כל ה-DCs מסתנכרנים מולו, וכל תחנות הקצה מסתנכרנות מול ה-DCs. פספוס של יותר מ-5 דקות יקריס לכם את מערך ההזדהות של Kerberos.
• ▸ניהול GPO: כשאתם פותחים את ה-Group Policy Management כדי ליצור פוליסי חדש, אתם עובדים כברירת מחדל ישירות מול ה-PDC.
• ▸DFS Namespace: שומר תמונה מעודכנת של נתיבי הרשת ואיזה שרת אחראי על איזה Site.

4. Infrastructure Master – המתרגם הארגוני. תפקידו לעדכן רפרנסים בין דומיינים שונים בתוך אותו Forest. אם משתמש מדומיין A הוזז, נמחק או שונה, והוא חבר בקבוצה בדומיין B, ה-Infrastructure Master ידאג לעדכן את ה-SID שלו כדי שההרשאות לא יישברו.

טיפ של מומחים מהשטח: אם כל ה-Domain Controllers שלכם מוגדרים גם כ-Global Catalog (וזה המצב ב-99% מהארכיטקטורות כיום) – התפקיד הזה למעשה נותר חסר משמעות, כי ה-GC כבר מחזיק את המידע על כלל האובייקטים ביער ולכן אף שרת לא זקוק ל'עדכוני רפרנס'.

5. RID Master (Relative ID) – משרד הפנים של המזהים. כדי ליצור משתמש חדש ולהעניק לו תעודת זהות פנימית (SID - Security Identifier), ה-DC שלכם חייב לשלב את מספר הדומיין הקבוע עם מספר סידורי ייחודי למשתמש שנקרא RID. כדי למנוע מצב ששני שרתים שונים יוצרים שני משתמשים עם אותו מספר, ה-RID Master לוקח את המאגר המלא ומחלק 'בלוקים' (לרוב של 500 מספרים) לכל DC. כש-DC מנצל כ-50% מהבלוק שלו, הוא פונה חזרה ל-RID Master ומבקש הקצאה חדשה.

מעבר ל-FSMO: מושגים קריטיים להבנת הארכיטקטורה

Bridgehead Server – ה'שגריר' של הסניף. המידע ב-AD מחולק ל-Partitions, וכל אחד מהם מרופלק באופן עצמאי. כאשר יש לכם מספר אתרים פיזיים (Sites), אתם לא רוצים שכל DC בסניף תל אביב ידבר ישירות עם כל DC בסניף ניו-יורק – זה 'יחנוק' לכם את קווי התקשורת (WAN). כאן נכנס תפקיד ה-Bridgehead. זהו השרת הנבחר בתוך ה-Site שתפקידו לאסוף את כל העדכונים מהסניף שלו, לדחוס אותם, ולשלוח אותם ל-Bridgehead שבסניף השני. ברגע שהמידע נוחת ביעד, ה-Bridgehead המקומי מפזר אותו לשאר ה-DCs בסניף.

KDC (Kerberos Key Distribution Center) – הסלקטור של הרשת. זהו השירות הקריטי שרץ על כל Domain Controller ואחראי על הליך האימות (Authentication). ה-KDC הוא המנוע שמאחורי פרוטוקול Kerberos v5. כאשר משתמש מבצע Logon, ה-KDC בודק את זהותו ומנפיק לו 'כרטיס כניסה' (TGT - Ticket Granting Ticket). בזכות הכרטיס הזה, המשתמש יכול לגשת לתיקיות משותפות, שרתים ואפליקציות ברחבי הרשת (SSO) מבלי שהסיסמה שלו תשודר באוויר אפילו פעם אחת.

השורה התחתונה לאנשי System

תכנון נכון של Active Directory מודרני לא מסתכם ב-Next, Next, Finish. הבנה עמוקה של תפקידי ה-FSMO, חלוקה נכונה שלהם בין שרתים שונים בסביבות עמוסות (Best Practices של מיקרוסופט), ותכנון נכון של טופולוגיית הרפליקציה (Bridgehead ו-Site Links) – הם ההבדל בין רשת מקרטעת לרשת שעובדת כמו שעון שוויצרי (או כמו ה-PDC Emulator שלכם).

בקורס System Administrator של נטמי אתם בונים את הסביבה הזו בידיים: מקימים Domain, מחלקים תפקידי FSMO, מתכננים Sites ו-Site Links, שוברים ומתקנים רפליקציה, ומבינים בדיוק מה קורה מתחת למכסה המנוע — בעברית, עם מרצים מהתעשייה וגישה לכל החיים.