محمد نصیری
بنیانگذار انجمن تخصصی فناوری اطلاعات ایران ، هکر کلاه خاکستری ، کارشناس امنیت اطلاعات و ارتباطات

RODC چیست و چگونه کار می کند به زبان بسیار ساده

RODC چیست؟ دومین کنترلر فقط خواندنی چیست؟ حتما در خصوص RODC مطالعاتی داشته اید و ممکن است هر کس از شما سئوال بکند بگویید که RODC مخفف کلمه های Read Only Domain Controller یا Domain Controller فقط خواندنی است و معمولا این برداشت می شود که این یک کپی کامل ولی خواندنی از پایگاه داده اکتیودایرکتوری شما است که در سایت های مختلف شبکه خودتان قرار می دهد. این موضوع بارها در انجمن تخصصی فناوری اطلاعات ایران مطرح شده است و به همین دلیل امروز تصمیم گرفتم در خصوص نحوه عملکرد RODC در شبکه برای شما مقاله ای بنویسم.

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

طبیعتا زمانیکه صحبت از RODC می شود شما از آن در شعبه ها یا نمایندگی های شرکت یا سازمان خود می خواهید استفاده کنید تا کاربران آن شبکه بتوانند به راحتی به سیستم ها و سرویس های مورد نیاز شبکه Login کنند. اما آیا تا به حال به این موضوع فکر کرده اید که چه فرآیندی بر روی RODC انجام می شود که باعث احراز هویت شدن یا Authenticate شدن کاربران می شود ؟ این خیلی مهم است که در زمان استفاده از RODC درست متوجه بشویم که Authentication چگونه انجام می شود.

اول از همه یک نکته را در نظر داشته باشید که در RODC هیچ پسوردی بصورت پیشفرض ذخیره نشده است و به همین خاطر نباید نگران به سرقت رفتن اطلاعات موجود در آن باشید ، البته این یک فرضیه است. قبل از هرگونه توضیحی این موضوع را هم فراموش نکنید که تمام نیاز کاربران شما در شعبه ها و نمایندگی های شما فقط Login کردن داخل سیستم نیست و شما باید بدانید که احراز هویت توسط پروتکل Kerberos انجام می شود که پروتکل احراز هویت پیشفرض اکتیودایرکتوری است.

در دنیای Kerberos چند قانون اصلی وجود دارد ، مهمترین قانون در Kerberos این است که اگر شما Ticket احراز هویت نداشته باشید ، بنابراین احراز هویت هم نمی شوید و دسترسی ها برای شما باز نخواهند شد.شما از Kerberos برای همه سرویس های دامین استفاده می کنید

برای انجام برخی کارها حتی کامپیوترها نیز در اکتیودایرکتوری بایستی احراز هویت شوند چه برسد به کاربران ، بنابراین بسیار ضروری و الزامی است که شما سیستم احراز هویتی خودتان را که در دفتر مرکزی دارید در شعبه ها و نمایندگی ها هم داشته باشید و از همه مهمتر شما باید سیستمی داشته باشید که حتی در صورت از بین رفتن لینک و ارتباط بین دفتر اصلی و شعبه یا نمایندگی ، همچنان بتواند احراز هویت کاربران را نیز انجام بدهد.

طبیعی است که شما هیچوقت ریسک قرار دادن کل Domain Controller خودتان به عنوان یک DC خواندنی نوشتنی در شعبه ای که بعضا کارشناس فنی هم ندارد را انجام نمی دهد. در اینجاست که شما از مکانیزمی باید استفاده کنید که ضمن اینکه احراز هویت را بتواند بصورت Offline و از طریق نام کاربری و رمز عبور Cache شده انجام دهد بتواند ریسک امنیتی شما را نیز به حداقل برساند. شما در چنین مواردی از RODC استفاده می کنید.

خوب حالا ما می خواهیم یک سناریو برای شما مثال بزنیم ، فرض کنیم که انجمن تخصصی فناوری اطلاعات ایران دارای یک مرکز اصلی یا Headquarter در کرج است و در تهران هم یک شعبه دارد که تعدادی کاربر در تهران مشغول به فعالیت هستند ، می خواهیم بدانیم که وقتی یک ماشین در شبکه شعبه تهران روشن می شود و می خواهد به یک فایل سرور که در شبکه همان شعبه قرار دارد متصل شود که در همان سایت قرار دارد چه اتفاقی می افتد ؟

در این سناریو ما فرض را بر این گذاشته ایم که کاربر ما برای اولین بار در شبکه شعبه تهران می خواهد از RODC برای Login کردن به شبکه استفاده کند و در حال حاضر هیچ پسوردی در RODC بصورت Cache شدن نگهداری نمی شود. ما سعی می کنیم مطالب را بصورت ساده بیان کنیم هر چند ساختار احراز هویت در اکتیودایرکتوری اصلا ساده نیست ولی ما می خواهیم تا جای ممکن این فرآیند را برای شما ساده سازی کنیم.

احراز هویت ماشین ها و کاربران در RODC چگونه انجام می شود؟

مکانیزم احراز هویت ماشین ها و کاربران در اکتیودایرکتوری تا حدود زیادی شبیه به هم و یکسان است. کلاینت ها از طریق DNS سرور و فرآیند DCLocator متوجه می شود که که سرور RODC ای که در همان سایت وجود دارد عملیات احراز هویت را باید اتجام دهد و در اصطلاح فنی تر DCLocator تشخیص می دهد که RODC وظیفه Authoritative Authentication را بر عهده دارد. همانطور که در تصویر زیر مشاهده می کنید در اولین گام کلاینت درخواست احراز هویت خودش را به سمت سرور RODC ارسال می کند.

در گام دوم سرور RODC به پایگاه داده خود که فایلی به نام NTDS.DIT است نگاه می کند تا ببیند آیا نام کاربری و رمز عبور کلاینت مورد نظر را بصورت ذخیره شده در پایگاه داده موجود دارد یا خیر ؟ با توجه به اینکه اطلاعات احراز هویت این کلاینت در پایگاه داده فعلی RODC قرار ندارد بنابراین RODC گام سوم را شروع می کند. در مرحله سوم RODC درخواست احراز هویت کلاین را از طریق لینک شبکه WAN به سمت سرور DC اصلی هدایت می کند و طبیعتا می داند که در آنجا باید اطلاعات در پایگاه داده وجود داشته باشد.

در گام چهارم RWDC ما از پایگاه داده خود اطلاعات مربوط به احراز هویت را بررسی می کند و با توجه به اینکه در این قسمت اطلاعات در پایگاه داده وجود دارد در گام پنجم پاسخ را به سمت سرور RODC هدایت می کند که حاکی از صحت اطلاعات درخواستی احراز هویت می باشد. در گام ششم که مرحله بعدی است درخواست کلاینت سرویس دهی شده است و کلاینت می تواند در فایل سرور احراز هویت و Login کند اما طبیعتا از این موضوع خوشحال نیست که چرا خودش احراز هویت را انجام نداده است .

برای اینکه مجددا شرمنده کلاینت ها نشود اینبار اطلاعات احراز هویتی کلاینت که کامپیوتر یا کاربر است در پایگاه داده RODC بصورت Cache شده نگهداری می شود تا در درخواست های احراز هویت بعدی کلاینت به جای سئوال کردن از سرور RWDC از اطلاعات خودش برای احراز هویت استفاده کند. برای اینکار ابتدا RWDC بررسی می کند که آیا Password Replication Policy خودش قابلیت Cache کردن پسوردها به RODC را داده است یا خیر ، اگر این اجازه داده شده بود ، اطلاعات احراز هویت آن کاربر در پایگاه داده RODC از این به بعد وجود خواهد داشت.


RODC چگونه کار می کند

خوب تا اینجای کار اگر مجددا کاربر یا کامپیوتر ما درخواست احراز هویت را به سمت RODC بفرستد ، فرآیند احراز هویت حتی با قطع شدن ارتباط شبکه WAN نیز انجام می شود و کاربر قادر به Login خواهد بود. اگر فرآیند Password Replication ای که عنوان کردیم در مرحله قبل انجام نمی شد RODC در صورت بروز مشکل برای لینک شبکه WAN دیگر قادر به احراز هویت نبود و درخواست کلاینت ما بی نتیجه می ماند. در مرحله بعدی می خواهیم در خصوص فرآیند دریافت Ticket و همچنین چگونگی دسترسی به سرویس مورد نظر صحبت کنیم.

در قسمت قبلی در خصوص نحوه ساده ترین احراز هویت در ساختار RODC صحبت کردیم و متوجه شدید که به صورت کلی RODC چگونه کار می کند و پسوردهای ما چگونه ذخیره می شوند. اما آیا همه چیز در شبکه دامین و اکتیودایرکتوری برای احراز هویت همین پسورد است ؟ در پاسخ به شما باید بگوییم خیر ، پسورد قسمتی از مسئله است و مسئله بعدی در احراز هویت و دسترسی به سرویس های ما مجوز دسترسی یا Ticket احراز هویت و دسترسی است.

همانطور که قبلا هم در توسینسو گفته ایم ، پروتکل اصلی احراز هویت در اکتیودایرکتوری Kerberos است ، هرگاه شما بخواهید به یک سرویس در شبکه اکتیودایرکتوری متصل شوید و از آن استفاده کنید بایستی برای خودتان یک Ticket دسترسی داشته باشید.

به این بلیط یا Ticket دسترسی به سرویس ها Ticket Granting Ticket یا TGT گفته می شود. این Ticket توسط یک سرویس به نام Key Distribution Center یا KDC ایجاد و صادر می شود که همیشه سرور Domain Controller ما در شبکه نقش KDC را بر عهده دارد و مدیریت Ticket های دسترسی هم بر عهده همین DC است.

ما فقط باید آنها را درخواست بدهیم ، در این مثال ما یک Ticket دسترسی را باید درخواست بدهیم که بتوانیم از سرویس File Server موجود استفاده کنیم. ما برای درخواست سرویس از فایل سرور نیاز به یک Ticket سرویس داریم ، زمانیکه این Service Ticket را دریافت کردیم می توانیم به سمت فایل سرور برویم و از آن درخواست سرویس کنیم.

فایل سرور یا هر سرویسی که قرار است به ما سرویس بدهد با توجه به Ticket ای که به آن ارائه می کنیم به ما اجازه می دهد که به منابع دسترسی پیدا کنیم و یا اصلا اجازه دسترسی به ما نخواهد داد. اما این فرآیند زمانی است که شما در شبکه RWDC دارید ، زمانیکه شما در شبکه از RODC استفاده می کنید قضیه کمی متفاوت تر خواهد بود ، به تصویر زیر دقت کنید ، مراحل اضافه ای که باید در RODC برای انجام همین کار طی شود را مشاهده می کنید :

RODC چگونه کار می کند RODC چیست

تصور کنید که یک کاربر قرار است تغییراتی بر روی یک فایل متنی که درون فایل سرور قرار گرفته است ایجاد کند. برای اینکه بتواند اینکار را انجام بدهد بایستی یک Ticket سرویس برای فایل سرور تهیه کند. در گام اول کاربر درخواست Ticket خودش را به سمت RODC ارسال می کند. با توجه به مثال بالا و مقاله قبلی فرض می کنیم که در گام دوم هنوز RODC کاربر را نمی شناسد و باید اون را احراز هویت کند ، با توجه به اینکه RODC تیکت کاربر را ندارد که بخواهد آن را احراز هویت کند در گام سوم درخواست Ticket را به سمت RWDC ارسال می کند.

RWDC تیکت مورد نظر را در گام چهارم بررسی می کند و در مرحله پنجم با توجه به صحت داشتن اطلاعات کاربر Ticket دسترسی را صادر و به سمت RODC ارسال می کند ، اگر یک DC معمولی در اینجا داشتیم ، اینجا همان زمانی بود که کاربر Ticket را دریافت می کرد اما در اینجا ما یک RODC داریم.

در اینجا RODC متوجه می شود که یک Ticket دسترسی به صورت موفقیت آمیزی ایجاد شده است و پسورد کاربر مورد نظر نیز در پایگاه داده RODC وجود دارد حالا RODC یک حقه کوچک را بکار می برد. در مرحله ششم RODC به کاربر مورد نظر اعلام می کند که Ticket درخواستی شما نامعتبر است و اشتباه وارد شده است.

در همین حین کاربر همه درخواست های قبلی خودش را کنار می گذارد و همه موارد را از ابتدا شروع می کند که این مرحله هفتم از کار می شود. اینبار در مرحله هشتم کاربر مجددا درخواست Ticket می دهد اما اینبار RODC او را احراز هویت می کند و به وی Ticket دسترسی را ارائه می کند. با توجه به اینکه کاربر همچنان درخواست دسترسی به فایل سرور را دارد مجددا یک Ticket جدید ایجاد می کند و آن را به سمت RODC در مرحله نهم می فرستد.

اینبار RODC توانایی خواندن Ticket احراز هویت کاربر مورد نظر را دارد و به سادگی توسط RODC احراز هویت می شود و Ticket دریافت می کند. البته توجه کنید که اینبار RODC محاسبات جدید Ticket را انجام می دهد و Ticket ای ویژه RODC تهیه و توزیع می کند که در مرحله دهم بصورت کامل قابل مشاهده است.

حالا کلاینت Service Ticket خودش برای احراز هویت و استفاده از خدمات فایل سرور را دارد. خیلی راحت Ticket را بر می دارد و به سمت فایل سرور در مرحله یازدهم ارسال می کند و در نهایت دسترسی های لازم را دریافت می کند. دچار ابهام شدید ؟

اشکالی ندارد این امر کاملا طبیعی است ، کمی صبر کنید و فکر کنید و مجددا مقالات را ابتدا مرور کنید ، سعی کنید این مقالات را با پارک ارم مقایسه کنید ، آنجا هم شما باید ابتدا بلیط خریداری کنید و بلیط ها را به مسئول دستگاه بدهید و از خدمات استفاده کنید. هر چیزی را می توانید با اینگونه مثال ها بهتر درک کنید. اما ای تقریبا کلیات روشی است که احراز هویت در RODC انجام می شود.

البته تکنیک هایی وجود دارد که بتوانید برخی موارد احراز هویتی را به RODC بسپارید که از آن جمله می توان به Pre-Populate کردن آنها اشاره کنیم. به هر حال فراموش نکنید که RODC برای شعبات و نمایندگی های کوچکی که شما ریسک امنیتی نمی خواهید داشته باشید و از طرفی تیم پشتیبانی قوی ندارد یا اصلا هیچکس به این عنوان در محل حضور ندارد و یا در جاهایی که تعداد کلاینت ها بسیار کم است استفاده می کنید. امیدوارم مورد توجه شما قرار گرفته باشد.

  • آیا RODC یک دومین کنترلر فقط خواندنی صرف است؟

    بله ، بدون شک RODC یک دومین کنترلر فقط خواندنی است که امکان نوشته شدن و ایجاد کردن Object های جدید بر روی آن وجود ندارد اما نکته در اینجاست که اگر شما با کاربر Domain Admin بر روی RODC لاگین باشید و Object ای ایجاد کنید ، ابتدا این Object با PDC اصلی Replicate می شود و سپس مجدد روی RODC نوشته می شود و این احساس به وجود می آید که RODC هم قابل نوشتن است.
  • در کجا از RODC استفاده می کنیم؟

    معمولا در محیط هایی که بصورت شعبه ، شاخه یا شرکت تحت مدیریت مرکز ، شبکه طراحی می شود ، برای جلوگیری از تداخل کاری ، ایجاد Object های بی مورد در شعبه ها و شاخه ها از RODC استفاده می شود

محمد نصیری
محمد نصیری

بنیانگذار انجمن تخصصی فناوری اطلاعات ایران ، هکر کلاه خاکستری ، کارشناس امنیت اطلاعات و ارتباطات

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

نظرات