امیرحسین کریم پور
متخصص سرویس های مایکروسافت و مدیر ارشد توسینسو

FSMO چیست | کاملترین معرفی FSMO های اکتیودایرکتوری

Schema Master چیست؟ RID Master چیست؟ PDC Emulator چیست؟ Infrastructure Master چیست؟ Domain Naming Master چیست؟ کاربرد FSMO ها یا Operations Master ها در اکتیودایرکتوری چیست؟ در صورت نبودن هر یک از Fizmo ها یا Operatio Master های اکتیودایرکتوری چه مشکلاتی ممکن است پیش بیاید؟ و ...

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران

معرفی FSMO های اکتیودایرکتوری قسمت 1 : Schema Master چیست ؟

قبلاََ در Tosinso به صورت مفصل درباره اینکه FSMO چیست صحبت شده است پس اگر نمیدانید FSMO چیست شما را به خواندن مقاله معرفی FSMO ها یا Operation Master Roles از مهندس نصیری عزیز دعوت میکنم. در این سری مطالب قصد داریم درباره تک تک FSMO Role ها در اکتیودایرکتوری صحبت کنیم. خب همانطور که از عنوان این مطلب مشخص است میخواهیم درباره Schema Master صحبت کنیم.

Schema Master یکی از مهم ترین و اساسی ترین نقش است که یک دامین کنترلر میتواند عهده دارش باشد. اول از همه درباره Schema کمی صحبت کنیم تا دید بهتری راجع به موضوع بحث مان پیدا کنید. Schema در اکتیودایرکتوری مشخص میکند که جنس یک Object مانند User و یا Computer در پایگاه داده اکتیودایرکتوری چیست. به بیانی دیگر Schema کلاس یک Object و Attribute یا صفت های یک Object یا شیء را مشخص میکند.


تنها یک DC یا دامین کنترلر در Forest اکتیودایرکتوری میتواند عهده دار نقش Schema Master باشد که میتواند Schema ی اکتیودایرکتوری را بروزرسانی کند، و این DC بایستی هنگام بروز رسانی Schema روشن و در مدار باشد. هنگامی که این بروز رسانی به پایان رسید تغییرات را با دیگر دامین کنترلر ها در Forest یکسان سازی یا Replicate میکند. پس تا اینجا دریافتید که نقش Schema Master در محدوده Forest میباشد. به Schema Partition که در تمام Domain Controller ها موجود میباشد Schema Naming Context نیز میگویند.

به خاطر داشته باشید که هر جا صحبت از Partition در حوزه اکتیودایرکتوری شد منظور Naming Context است. نکته قابل توجه این است که از آنجا که Schema در اکتیودایرکتوری به ندرت تغییر میکند از این رو نقش Schema Master نیز به ندرت در اکتیودایرکتوری به کار می آید. سناریو هایی که این Role در اکتیودایرکتوری خود را نشان میدهد میتوان به پیاده سازی Exchange Server ، Skype for Business Server و یا Upgrade یا ارتقاء دامین کنترلر از یک ورژن به ورژن بالاتر اشاره کرد. در مطلب بعد درباره Domain Naming Master که دومین و آخرین نقش از FSMO Role ها در سطح Forest میباشد صحبت خواهیم کرد.

معرفی FSMO های اکتیودایرکتوری قسمت 2 : Domain Naming Master چیست؟

در مطلب قبلی بصورت مفصل درباره نقش Schema Master در اکتیودایرکتوری صحبت کردیم حال در این مطلب میخواهیم درباره دومین نقش که در سطح Forest فعالیت می کند و نامش Domain Naming Master است صبحت کنیم. خب برای درک بهتر این Role یا نقش در اکتیودایرکتوری فرض کنید که در ساختار اکتیودایرکتوری تان تعداد زیادی Domain و Child Domain دارید حال اگر به دلایلی بخواهید یک Domain Controller راه اندازی کنید که برای مثال یک Child Domain را ایجاد کنید وجود نقش Domain Naming Master الزامی خواهد بود زیرا اگر این Role نباشد سایر دامین کنترلر های در مجموعه نمی توانند از حضور این دامین کنترلر خبردار شوند. اکتیودایرکتوری اشاره گر هایی را در CrossRef object که خود در پارتیشن کانتینر در Configuration naming context می باشد ذخیره می کند.

این Object یا شی ء در اکتیودایرکتوری حاوی Attribute هایی است که شامل Distinguished name ، DNS name ، flat name و نام Domain naming context می باشد. وقتی شما یک Domain جدید در Forest تان ایجاد می کنید دومین جدید ایجاد شده دارای naming context جداگانه و یک CrossRef object جداگانه در پارتیشن کانتینر خواهد بود. توجه داشته باشید که تنها یک دامین کنترلر در Forest می تواند عهده دار نقش خطیر Domain Naming Master در ساختار اکتیودایرکتوری باشد شما هر چقدر هم Child Domain و Domain های جداگونه همراه با Additional DC داشته باشید باز شرایط به همین منوال است یعنی یک DC میتواند نقش Domain Naming Master را بر عهده بگیرد و بر روی پارتیشن کانتینر آن تغییرات بدهد. نقش Domain Naming Master باعث می شود که دو مدیر شبکه نتوانند دو Domain با یک نام یکسان در Forest ایجاد کنند و در حقیقت این نقش جلوی انجام شدن این کار را می گیرد.

به طور پیش فرض اولین دامین کنترلر ایجاد شده در Forest عهده دار نقش Domain Naming Master و هم عهده دار نقش Schema Master خواهد بود اما شما می توانید این دو نقش را به عهده هر دامین کنترلری در مجموعه بسپارید که قطعاََ آن دامین کنترلر باید بصورت خواندنی نوشتنی یا بعبارتی R/W DC و همچنین در نقش Global Catalog سرور باشد. شما به صورت گرافیکی این کار را از طریق کنسول مدیریتی Active Directory Domains and Trusts می توانید انجام دهید. در مطالب بعدی درباره نقش های مدیریتی اکتیودایرکتوری که در سطح Domain فعالیت می کنند صحبت خواهیم کرد.

معرفی FSMO های اکتیودایرکتوری قسمت 3: Infrastructure Master چیست؟

با ادامه معرفی نقش های مدیریتی اکتیودایرکتوری یا FSMO role ها در خدمت شما هستیم. در این نکته می خواهیم درباره نقش Infrastructure Master در اکتیو دایرکتوری که یک نقش فعالیت کننده در سطح Domain است به صورت مفصل صحبت کنیم. همانند سایر نقش های مدیریتی اکتیودایرکتوری ، نقش Infrastructure Master در یک Domain تنها در اختیار یک دامین کنترلر میتواند باشد اما در یک Forest بسته به تعداد دامین ها می تواند توسط چندین دامین کنترلر میزبانی شود.

هر دامین کنترلر در ساختار اکتیو دایرکتوری اطلاعات کاملی درباره تمامی Object های داخل Domain اش را ذخیره می کند. با این وجود ، سلسله مراتب Forest اکتیو دایرکتوری محدود به یک دامین نیست بلکه می تواند شامل چندین دامین نیز باشد. فعالیت های این دامین ها به هیچ وجه در ساز و کار اکتیو دایرکتوری تاثیر نمی گذارد تا زمانیکه Security Object هایی از یک دامین در یک دامین دیگر استفاده نشده باشد ... در عمل ، نمونه های کمی از ایزوله شدن یک دامین از یک دامین دیگر در یک Forest وجود دارد. به این معنی که در خیلی از اوقات یوزر هایی از یک دامین در گروهی از یک دامین دیگر در آن Forest عضو می شوند و با هم در تعامل هستند. نقش Infrastructure Master در اکتیو دایرکتوری مسئولیت چنین Scheme یا طرح هایی در هر دامین هستند.برای مثال در دامین B یک Security Group وجود دارد که شما میخواهید یوزر یا یوزر هایی از دامین A را در آن گروه عضو کنید. هنگامی که یوزر در آن گروه عضو میشود موارد زیر اتفاق می افتد :

  1.   دامین کنترلری که عهده دار نقش Infrastructure Master از دامین B می باشد به Global Catalog سرور دسترسی پیدا می کند تا اطلاعات مربوط به یوزر عضو دامین A را بدست بیاورد. زیرا GC سرور اطلاعات مهم از تمامی Object های موجود در Forest را در خود ذخیره می کند و تنها اطلاعات ضروری را دربردارد.
  2. دامین کنترلری که عهده دار نقش Infrastructure Master از دامین B می باشد یک Phantom Object از یوزر عضو شده در دامین A ایجاد می کند. Phantom Object یک نوع Object خاص در اکتیودایرکتوری است که توسط کنسول ADSI Edit و یا کنسول AD U&C و ... نمی تواند نمایش داده شود. Phantom record ها شامل حداقل اطلاعات درباره آن Object یا شی ء می باشند به عنوان مثال Distinguished name ، GUID و SID .
  3. نقش Infrastructure Master به طور پیش فرض هر 2 روز یکبار تمامی Phantom Object ها را با اطلاعات GC سرور مقایسه می کند، برای مثال اگر تغییری در Attribute های یوزر موجود در دامین A تغییر داده شود ( مثلا تغییر نام داده شود ، به یک دامین یا کانتینر دیگر منتقل شود ، حذف شود و ... ) Infrastructure Master تغییرات مناسب را در Phantom Object مربوط به آن Object صورت می دهد.

معرفی FSMO های اکتیودایرکتوری قسمت 4 : PDC Emulator چیست؟

سلام خدمت دوستان و کاربران عزیز وب سایت توسینسو. با ادامه معرفی نقش های مدیریتی اکتیودایرکتوری یا FSMO Role ها در خدمت شما عزیزان هستیم. در این نکته می خواهیم درباره نقش PDC Emulator در اکتیو دایرکتوری که یک نقش فعالیت کننده در سطح Domain است به صورت مفصل صحبت کنیم.

PDC Emulator مخفف Primary Domain Controller Emulator است و در یک Domain تنها در اختیار یک دامین کنترلر میتواند باشد. در ابتدا وظیفه اصلی نقش PDC Emulator اطمینان پیدا کردن از سازگاری در نسخه های قدیمی سیستم عامل ویندوز بود. در محیط هایی با نسخه های مختلف ویندوز های کلاینت نظیر NT4.0 ، ویندوز 95 و ویندوز 98 و دامین کنترلر های NT4.0 وظیفه نقش PDC Emulator (فقط برای آن نسخه ها) به شرح زیر بود :

- انجام فرآیند تغییر پسورد های کاربران و کامپیوتر ها
- Replication آپدیت ها به BDC یا Backup Domain Controller
- اجرا کردن کار های مربوط به Domain Master Browser

با شروع به کار کردن و ارائه ویندوز سرور 2000 وظایف نقش PDC Emulator به شرح زیر می باشند :

1. تغییر پسورد ها درهر یک از دامین کنترلر ها با Primary DC در ابتدا Replicate می شود. اگر احرازهویت در هر یک از دامین کنترلر ها با موفقیت انجام نگیرد درخواست به PDC Emulator صادر می شود. اگر یوزر اکانت بعد از یک تلاش ناموفق بلافاصله با موفقیت احرازهویت شد PDC Emulator این اتفاق را اطلاع رسانی می کند و تعداد تلاش های ناموفق برای احرازهویت را ریست می کند. به این نکته مهم توجه کنید که اگر دامین کنترلری که نقش PDC Emulator را بر عهده دارد در دسترس نباشد اطلاعات پسورد تغییر کرده در دامین در کل دامین پخش می شود. این کار با سرعت کمی انجام می شود.
2. Group Policy Editor بصورت پیش فرض به سرور PDC Emulator متصل شده است و تمامی تغییرات صورت گرفته در GPO ها در خودش اتفاق می افتد. اگر دامین کنترلری که نقش PDC Emulator را بر عهده دارد در دسترس نباشد ضروری است که مشخص کنید که به کدام دامین کنترلر میخواهید متصل شوید.
3. بصورت پیش فرض PDC Emulator به عنوان Time server نیز برای کلاینت های دامین ایفای نقش می کند. PDC Emulator ای که در Root Domain در Forest قرار دارد Time server پیش فرض برای PDC Emulator های موجود در Child Domain است.
4. ایجاد تغییرات در DFS Namespace توسط دامین کنترلر در نقش PDC Emulator انجام می شود. DFS root server ها اطلاعات Update Metadata ها را بصورت دوره ای از PDC Emulator می خواهند. در دسترس نبودن سرور PDC Emulator موجب عمل نکردن صحیح DFS Server ها می شود. البته DFS های Active Directory Integrated نه Stand alone.
5. انجام فرآیند بالا بردن سطوح عملیاتی اکتیودایرکتوری یا بعبارتی Forest Functional Level و Domain Functional Level نیز توسط PDC Emulator انجام می شود.
6. در طول نصب اولین Domain Controller در دامین سرویس Net Logon در DNS سرور SRV رکورد -ldap.-tcp.pdc.-msdcs.DnsDomainName را ایجاد می کند. این SRV رکورد به کلاینت ها این اجازه را می دهد که PDC Emulator را در دامین پیدا کنند. تنها دامین کنترلری که عهده دار این Role هست میتواند این SRV Record را ویرایش کند.
7. اکتیودایرکتوری Well Known Security Principal هایی دارد که شامل گروه های Everyone ، Authenticated Users, System ، Creator Owner و ... می شود. همه این Security Principal ها توسط دامین کنترلر در نقش PDC Emulator مدیریت می شود.
8. مکانیزم SDProp یا Security Descriptor Propagator در دامین کنترلر PDC Emulator اجرا می شود. این مکانیزم میتواند ACL های تنظیم شده روی Object های اکتیودایرکتوری را پاک کند.

Best Practice های مایکروسافت برای نگهداری از PDC Emulator

1. FSMO Role های PDC Emulator و RID Master را در یک دامین کنترلر نگهداری کنید.
2. مطمئن شوید که دامین کنترلر PDC Emulator با یک Time server معتبر زمان خودش را Synchronize می کند.
3. اگر دامین کنترلر هایتان در محیط مجازی سازی شده قرار دارند مطمئن شوید که زمان خودشان را با Virtualization Host ای که در آن قرار دارند (مثل ESXi یا Hyper-V) همگام سازی یا Synchronize نمی کنند.
4. مکانیزم کاری SDProp را تغییر ندهید.

معرفی FSMO های اکتیودایرکتوری قسمت 5 : RID Master چیست ؟

با ادامه معرفی نقش های مدیریتی اکتیودایرکتوری یا FSMO Role ها در خدمت شما عزیزان هستیم. در این نکته می خواهیم درباره نقش RID Master در اکتیو دایرکتوری که یک نقش فعالیت کننده در سطح Domain است به صورت مفصل صحبت کنیم. RID Master مخفف Relative Identifier است و در یک Domain تنها در اختیار یک Domain Controller میتواند باشد.

دامین کنترلری که عهده دار این نقش است وظیفه اختصاص دادن توالی منحصر بفردی از RID ها را به هر Domain Controller در دامین بر عهده دارد. RID Master همچنین وظیفه بصورت صحیح انتقال دادن Object ها از یک دامین به یک دامین دیگر را بر عهده دارد. بعبارت دیگر این FSMO Role وظیفه اختصاص دادن SID یا Security Identifier های منحصر بفرد به هر Object (یوزر ، کامپیوتر ، گروه ، و ...) در اکتیودایرکتوری را بر عهده دارد.

وقتی Administrator یک Object جدید ( یا یک Security Principle جدید ) در اکتیودایرکتوری ایجاد می کند یک SID منحصر بفرد به آن اختصاص داده می شود. SID ای که به این Object ها اختصاص داده می شود ترکیبی از Domain SID و Relative SID یا RID است و از RID Pool دامین کنترلر فعلی به آن ها اختصاص داده می شود. پس دانستیم که RID Master مسئولیت اختصاص دادن SID ها به Object ها را بر عهده دارد.

RID ها بصورت پیش فرض بصورت قطعه های 500 تایی به Domain Controller ها صادر می شود و اگر لازم باشد تعداد RID های درخواستی میتوان آنرا تغییر داد. اگر کمتر از 50 درصد یا بعبارتی نیمی از Identifier ها در Pool باقی مانده باشد دامین کنترلری که عهده دار نقش RID Master است Pool آن دامین کنترلر را پر می کند. برای اینکه لیستی از SID های همه یوزر های دامین را مشاهده کنید دستور زیر را در PowerShell اجرا کنید :

get-aduser –filter *|fl sid

با اجرای دستور زیر نیز میتوانید وضعیت رول RID Master را مشاهده کنید :

Dcdiag.exe /TEST:RidManager /v

در خروجی دستور بالا میتوانید تعداد SID های باقی مانده در دامین کنترلر فعلی را مشاهده کنید.

همانطور که گفته شد مسئولیت دیگری که نقش RID Master بر عهده دارد انتقال Object ها از یک دامین به دامین دیگر است. RID Master اطمینان حاصل می کند که یک Object بصورت همزمان به دو دامین انتقال داده نشود. در غیر این صورت ، دو دامین دارای Object هایی با GUID های یکسان خواهند بود. زمانیکه یک Security Object (مانند یوزر اکانت) از یک دامین به یک دامین دیگر انتقال داده می شود به آن Object یک SID جدید تعلق میگیرد و SID قدیمی آن در Attribute ای به نام SIDHistory نوشته می شود. این Attribute تمامی SID های Object هایی را که تغییر یافته اند را در خودش ذخیره می کند. خب بهتر است Best Practice های مایکروسافت را نیز در مورد RID Master Role در اکتیودایرکتوری عنوان کنیم :


  1.   FSMO Role های PDC Emulator و RID Master را در یک دامین کنترلر نگهداری کنید.
  2. اگر به دلایلی دامین کنترلری که نقش RID Master را بر عهده دارد از مدار خارج شود شما باید این Role را به اجبار در دیگر دامین کنترلر ها نیز Seize کنید و حتما به خاطر داشته باشید که آن دامین کنترلر که Seize شده دیگر نباید به مدار باز گردد و باید خاموش نگه داشته شود.
  3. اگر به دامین کنترلر RID Master با مشکل مواجه شود میتوانید EventID های بین شماره های 16653 تا 16658 را در Event Viewer برای برطرف کردن مشکل بررسی کنید.
  4. اگر دامین کنترلر RID Master از مدار خارج شود بعد از مدتی قادر نخواهید بود تا Object جدید در اکتیودایرکتوری ایجاد کنید.


برای اینکه نقش RID Master را از یک دامین کنترلر به دامین کنترلر دیگر انتقال دهید وارد کنسول ADUC شوید و به Domain Controller ای که میخواهید RID Master Role آنرا انتقال دهید وصل شوید ( از طریق راست کلیک رو دامین و انتخاب گزینه Change Domain Controller ) و روی Domain راست کلیک کنید و گزینه Operations Masters را انتخاب کنید. حالا به تب RID بروید و روی Change کلیک کنید. اگر Role به درستی انتقال داده شود با پیغام Success روبرو خواهید شد. امیدوارم مورد توجه شما قرار گرفته باشد. 

  • ّFSMO یا Operations Master ها در اکتیودایرکتوری چه هستند؟

    در واقع اینها نقش های مدیریتی با وظایفی مشخص هستند که 5 عدد هستند و هر کدام وظیفه یک چیز در اکتیودایرکتوری را بر عهده دارند ، برای مثال وظیفه کنترل زمان ، وظیفه معرفی قالب ساخت اشیاء در اکتیودایرکتوری و ... بر عهده آنهاست.

امیرحسین کریم پور
امیرحسین کریم پور

متخصص سرویس های مایکروسافت و مدیر ارشد توسینسو

امیرحسین کریم پور ، مدیر ارشد توسینسو ، متخصص شبکه ، تخصص در حوزه سیستم عامل های کلاینت و سرور مایکروسافت و سرویس های مربوطه ، سیستم عامل لینوکس و ... ، سابقه کار با سازمان ها و شرکت های مختلف در زمینه سرویس های مایکروسافت در قالب پروژه ، مشاوره و آموزش ، علاقه مند به حوزه امنیت اطلاعات و تست نفوذ سنجی

25 آذر 1396 این مطلب را ارسال کرده

نظرات