מוסבר: איך עובדים תפקידי FSMO של Active Directory

מדריכים

Active Directory (AD) הוא שירות ספרותי המספק שירותי אימות ואישור מרכזיים. ארגונים מארחים את AD על בקרי דומיין (DCs) שמשכפלים מידע ביניהם בתצורת מרכז-רבים. תפקידי הפעולה הראשיים של מאסטר יחיד גמיש (FSMO) מבטיחים נתונים עקביים ואמינים בכל מקורי הנתונים.

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

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

מהם תפקידי FSMO?

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

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

FSMO Role Scope
Schema Master Forest
Domain Naming Master Forest
Primary Domain Controller Emulator Domain
RID Master Domain
Infrastructure Master Domain

A DC can hold multiple roles at one time.

תפקיד מאסטר הסכמה

A critical component of AD is the database. The database, like all other databases, has a schema that dictates its structure with various partitions or naming contexts. The AD schema is a database partition that contains metadata about AD objects. For example, it contains classes like person, group, or msPKI-Key-RecoveryAgent and attributes like phone number, badPwdCount, or dNS-HostName.

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

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

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

מאסטר שם דומיין

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

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

מודרך השלט הראשי (PDCe)

ללא ספק, התפקיד FSMO החיוני ביותר ב-AD הוא ה-PDCe. תפקיד ה-PDCe אחראי למשימות כמו סנכרון שינויי סיסמה, נעילת חשבון (ופתיחתו), סנכרון זמן ועוד.

בימי ההתחלה של סקירת פעילות (Active Directory) (Windows NT), ממנהל הדומיין הראשי (PDC) היה המחשב הבלעדי שניתן לכתיבה ברשת סקירת פעילות (AD). כל מחשבי הדומיין האחרים היו מחשבי בקרת דומיין גיבויים (BDCs) השמשו רק לבקשות אימות

החל מ- Windows 2000, כל מחשבי הדומיין הפכו להיות ניתנים לכתיבה כולם למעט שלטי הדומיין לקריאה בלבד (RODCs), שהוצגו ב- Windows Server 2008. בשל צורך עדיין בפונקציונליות של מנהל הדומיין הראשי אך כבית טכני לא הייתה לו עוד תפקיד מנהל הדומיין הראשי, מיקרוסופט הכניסה את תפקיד ממיר מנהל הדומיין הראשי (PDCe).

הפניה של יישומי מורשות

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

סנכרון זמן

חשוב שכל התקנים שמצטרפים לדומיין ישמרו זמן עקבי. אימות Kerberos (מצב האימות ברירת המחדל) מחייב פער מרבי של חמישה דקות בין לקוח ל-MC או בין שותפי שינוי דומיין (DC) של שינוי.

תפקיד ממיר מנהל הדומיין הראשי הוא מקור הזמן המרכזי לכל מחשבים אחרים ביער AD.

  1. כל מחשבי הלקוח מסנכרנים זמן מה- DC שהם נכנסים אליו.
  2. את כל שרתי המרכז באזור (DCs) מסנכרנים את הזמן משרת הזמן הראשי בתחום שלהם (PDCe).
  3. ביערות AD רב-תחומים, שרתי המרכז המארחים את תפקיד PDCe מסנכרנים את הזמן משרת הPDCe בתחום ההורית.
  4. תפקיד הPDCe בתחום השורש משתמש אז במקור חיצוני ואמין של זמן כדי לבצע סנכרון.

ניהול שינויים בסיסמאות

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

לדוגמה, אם DC אינו מכיל כרגע את הסיסמה האחרונה ומשתמש מנסה לאמת עם הסיסמה הישנה, ה-DC שמאמת יפנה תחילה אל ה-DC ששומר על תפקיד הPDCe כדי לבדוק עבור סיסמה מעודכנת לפני דחיית אימות.

תשים לב לבעיות עם הPDCe מיד כאשר אתה מגלה משתמשים ששינו סיסמה ויש להם בעיות בהתחברות ל-DCs אחרים שטרם שומרים על הסיסמה החדשה.

עיבוד נעילות חשבון

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

מטרת ברירת המחדל עבור מסוף ניהול מדיניות הקבוצה (GPMC) של מדיניות הקבוצה

ניהול מדיניות הקבוצה נעשה עם כלי מנהל מדיניות הקבוצה (GPMC). כדי לבצע שינויים ב- AD, יש ל-GPMC להתחבר ל- DC. לפי ברירת המחדל, ה-GPMC תתחבר תמיד ל- DC ששומר על תפקיד ה- PDCe, גם אם הוא ממוקם ב- אתר AD שונה. אם אין אפשרות להתחבר ל- PDCe, תקבל אזהרה שטפקיד ה- PDCe אינו נגיש וה-GPMC יבקש ממך לבחור DC אחר.

The GPMC would really prefer to talk to the PDCE.

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

ספק של מידע אודות מרחב שמותם של מערכת הקבצים המבוזרת (DFS)

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

אמנם לא מכמילה רגילה עבור תפקיד ה-PDCe FSMO, אתה משנה את ההתנהגות גלישת ה-DFS המותרת בסביבות עם מספר גדול של שרתי DFS.

RID Master

כל אובייקט בדומיין AD חייב לקבל זיהוי ייחודי כדי להבחין אותו מכל האובייקטים הדומים האחרים. חיוני ש-AD תמיד תקציב זיהוי ייחודי לכל אובייקט חדש הנקרא מזהה אבטחה או SID.

כל SID מורכב מ-מספר רכיבים: S (ל-SID), מספר ה-Revision, I – ה-Authority של המזהה -, זיהוי הדומיין, והזיהוי היחסי. זיהוי הדומיין הוא ייחודי לכל דומיין ביער. הזיהוי היחסי ייחודי לכל אובייקט בדומיין. SID נראה כך עם DomainId המייצג את זיהוי הדומיין ו-RelativeId המייצג את הזיהוי היחסי.

S-Revision-I-DomainId-Rid

Example: S-1-5-12-7273811915-2261004348-033256673-515
The string identifies this value as a SID. The string starts with an "S";
And has a revision level of 1;
An identifier authority value of 5 (NT Domain);
The domain identifier is a four-part value, 
The RID has a value of 515. The value of the RID is fixed and will never be generated; it's hard-coded and won't be repeated. (In this example, this is the well-known SID for the Domain Computers security group).

התפקיד של ה-Relative ID (RID) Master מבטיח שה-SID המוקצה לכל אובייקט AD הוא ייחודי.

כמה RIDs מורשים עבור חשבונות מיוחדים וקבוצות ידועות.

ה-DC הראשון בדומיין משמש באופן אוטומטי כ- RID Master, כדי לשמור על שליטה בהנפקת RID.

ה-DC המחזיק בתפקיד RID Master משתמש בעיקר בשלוש אירועים שונים:

קידום/הורדת דרגת DC

בכל פעם ש-DC חדש מתקדם, ה-RID Master מקצה לו קבוצת 500 RIDs. ה-RIDs האלו משוייכים (בסדר עולם) כאשר חשבון חדש שצריך SID נוצר ב-DC זה.

לדוגמה, אם הקבוצה האחרונה של RIDS שהוקצתה הייתה מ- 5501 עד 6000, ה-DC הבא שזקוק לקבוצה (בהתקדמות חדשה או DC שפרק את הקבוצה הנוכחית שלו) יקבל 6001 עד 6500 וכן הלאה.

כאשר DC נמחק ממסד ה-AD, ה-RID Master זהה זאת ווודא שלא יתבצע שיוך של כל RIDs שהיו ל-DC זה, כחלק מהזהירות למניעת SID כפולים.

חילוף של RIDs

כאשר DC מגיע ל-50% מקצוע ה-RID, הוא יתבקש מה-RID Master לקבוצת חדשה של RIDs. DCs יבקשו RIDs חדשים כשהם ב-50%, במקרה ש-RID Master אינו מקוון, וזה יאפשר זמן מספר רב של בופר לוודא שההקצאה שלו ל-RID אינה נגמרת.

החמישים במאה של RID

מנהלים יכולים להעביר תפקידים מ-DC אחד ל-DC אחר דרך חילוף או העברת תפקידי FSMO. כשמנהל מעביר את תפקיד RID Master מ-DC אחד ל-DC אחר, המספר הזמין הבא של RID יתר ב-10000.

קשור: איך להעביר תפקידי FSMO (ב-GUI וב-PowerShell)

הגברת ה-RID הבאה בקוד על ידי 10000 היא מנגנון בטיחות שמותקן כדי למנוע סידורי SIDs כפולים. אם מנהל יקבל את תפקיד ה-RID Master, לדוגמה, וה-RID Master הישן חוזר לפעולה, ייתכן שיתחיל להניף SIDs כפולים יחד עם ה-RID Master החדש.

ראשי מתשתיות

לכל אובייקט AD יש SID שמוקצה על ידי תפקיד ה-RID Master FSMO. כאשר אתה צופה במשתמשים, קבוצות ומידע AD אחר, אנו, בני אדם, רוצים לראות שם ולא SID; זהו המקום שבו מתפקד תפקיד מנהל התשתיות.

ברירת המחדל, כל DC מוגדר כקטלוג גלובלי (GC). GC מארח מידע מכל התחומים ביער. אחד הדרכים להפחתת תעבורת שידור בין אתרים הייתה להגדיר כמה DCs לא להיות GCs.

אם אתה מאומת ל-DC שאינו GC, מנהל התשתיות אחראי על תרגום SIDs מתחומים אחרים לשמות ידידותיים לאדם.

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

SID to name translation for other domain objects. On the left, the DC is not a GC and the IM role holder is not online. On the right, the DC is a GC (or the IM role holder is reachable).

אם תפעיל את אשפת ה-Active Directory, כל DCs פועלים באופן טכני כאילו הם מחזיקים בתפקיד מנהל התשתיות. אשפת ה-AD מעניקה לתפקיד מנהל התשתיות רול חשיבותי במילות הסקריפט של Microsoft. לא חשוב.

קשור: איך לשמור על בקן שלך עם אחסון מערכת הניהול הפעילה

מסקנה

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

Source:
https://adamtheautomator.com/fsmo-roles/