درس دوازدهم: پیکربندی Additional DC – بخش دوم

موضوع: پیکربندی Additional DC – بخش دوم

 

 

 

 

 

ایجاد RoDC با روش IFM

     RoDC نوعی additional DC است که یک نسخه read-only از AD DS دامین را در اختیار دارد. از RoDC در سایت های فیزیکی استفاده میشود. سایت هایی که از نظر امنیتی زیاد قابل اعتماد نیستند. فرض کنید که نیاز دارید که در یکی از شعب سازمان یک DC داشته باشید ولی هیچ اعتمادی به امنیت فیزیکی Server Room آن شعبه ندارید. در این حال برای شعبه فوق یک RoDC ایجاد میکنید. در RODC یک نسخه کامل از اکتیودایرکتوری وجود دارد که شامل نام های کاربری و سایراطلاعاتی است که در این ساختار وجود دارند ، البته قابل ذکر است که رمزهای ورود در این دامین کنترلر وجود ندارند. شیوه کار RoDC به این شکل است که به محض دریافت درخواست های Log on کاربران به Host ها، این درخواست ها از طریق RODC به DC اصلی فرستاده می شوند و DC اصلی آنها را احزار هویت کرده و به RODC بر می گرداند و به این ترتیب کاربر اجازه ورود به سیستم را بدست می آورد. پس از هر بار احراز هویت هر user رمز وی در سرور RODC کش می شود تا در دسترسی های بعدی سریعتر بتواند مجوز ورود را به وی بدهد . بصورت کلی ویژگیهای یک دامین کنترلر فقط خواندنی یا RODC به شرح زیر است:  

  • نسخه فقط خواندنی از اکتیودایرکتوری: در نتیجه کلاینت های به هیچ عنوان نمی توانند تغییری در ساختار DC ایجاد کنند مگر اینکه بخواهند رمز عبور خود را تغییر دهند .
  • فیلترینگ Attribute ها : با این قابلیت مدیران شبکه میتوانند بسادگی مواردی را که بایستی بین دامین کنترلر ها Replicate شوند را تعیین نمایند.
  • Read-Only DNS : تنظیمات DNS نیز مشابه تنظیمات خود RoDC فقط برای انجام درخواست خواندن استفاده می شوند و قابل ادیت نمی باشند. بدلیل Read-only بودن، رکوردهای این DNS نمیتوانتد بصورت dynamic آپدیت شود که خود همین امر باعث افزایش امنیت میگردد.
  • Account caching : با cache شدن اکانتها ، سرعت ورود افزایش پیدا کرده و ورود به host ها نیز بر اساس درخواستی خواهد بود که کلاینت به RoDC ارسال می کند و باعث صرفه جویی در زمان Replication نیز میشود.

       توصیه اکیدی وجود دارد که در هر Domain حداکثر یک RoDC وجود داشته باشد حتی اگر دامین فوق دارای چندین site فیزیکی باشد. اگر بیش از یک RoDC در یک دامین موجود باشد، فرآیند log on کردن کاربران به host ها دچار مشکلات عدیده ای میشود.

     رول های Operation Master ( در درسهای آینده با این رول ها به تفصیل آشنا خواهید شد) قابل پیاده سازی روی RoDC نیستند چون رول های فوق نیاز به دسترسی write به ابجکت ها و Attribute های دامین و forest دارند.

     RoDC فقط اطلاعات اکانتهای دامین متبوعش را میتواند cache کند. اگر در forest خود چند دامین داشته باشید، RoDC نمیتواند اطلاعات اکانتهای دامین های دیگر ( غیر از دامین خودش) را cache کند. در نتیجه اگر WAN Link بین شعبه و DC اصلی برقرار نباشد، زمانی که کاربران و کامپیوترهای دامین های دیگر قصد استفاده از منابع داخل دامین RoDC را داشته باشند، RoDC نمی تواند عملیات Authentication را انجام دهد.

     بعضی از Application ها مانند Microsoft Exchange Server بصورت مداوم با AD DS ارتباط برقرار میکنند. RoDC از پس ارتباط مداوم با این Application ها برنمی آید. لذا اگر در شعبه ای دارای چنین Application هایی می باشید باید یک Writable Additional DC در شعبه فوق قرار دهید.

RoDC  هم به روش سنتی قابل پیاده سازی است ( در صفحه Domian Controller Options از ویزارد DC Promote کافیست گزینه RoDC تیک زده شود) و هم به روش IFM .

 

ساخت فایل IFM و انجام پیش نیازها

     در اینجا قصد داریم روش IFM را توضیح دهیم. الگوریتم کلی دقیقا مانند ایجاد Writable Additional DC است که در مرحله قبل مشاهده کردید. ساخت فولدر IFM روی DC اصلی شبکه هم دقیقا مانند همان چیزی است که مشاهده کردید با این تفاوت که بجای دستور create full یا create sysvol full از یکی از دستورات ذیل استفاده میکنیم:

  • Create RoDC
  • Create sysvol RoDC ( به توضیحاتی که در مورد انتخاب این گزینه داده شد، دقت کنید. نیاز به انجام بعضی کارهای جانبی دارد)

     قصد ایجاد RoDC را داریم روی کامپیوتری به نام DC3 با تنظیمات ذیل: ( دقت کنید که در اینجا هم آدرس DC1 بعنوان Preferred DNS وارد شده است)

IP Settings on DC3

     اکنون روی همین کامپیوتر DC3 فولدری ایجاد میکنیم به نام IFM و دسترسی های لازم Share و NTFS را میدهیم.  

     در ذیل نحوه ساخت فایل ifm مخصوص RoDC در مسیر D:\\ روی DC1 را مشاهده میکنید. در این مثال IFM را بصورت RoDC  به همراه sysvol پیاده سازی میکنیم.

ifm with sysvol rodc

     اکنون چون از دستور create sysvol RoDC استفاده کرده ایم بلافاصله از محیط IFM و محیط NTDSUtil خارج میشویم. ( توسط دو بار وارد کردن دستور quit ) و در همان محیط cmd دستور ذیل را وارد میکنیم:

Robocopy.exe /E /COPYAll  D:\ifm  \\192.168.1.3\ifm

     سپس به DC3 می رویم. حتما قبل از  اینکه سرویس AD DS را رویش نصب کنیم، در پنجره properties فولدر sysvol که در فولدر ifm وجود دارد به تب security رفته و روی advanced کلیک می کنیم.

sysvol security

     حال در تب Auditing tab با کلیک روی Disable Inheritance وراثت را غیرفعال میکنیم.

 

استفاده از IFM روی RoDC

     اکنون روی DC3 اقدام به نصب سرویس AD DS میکنیم. اما گزینه ای که تعیین میکند در صورت نیاز کامپیوتر ReStart شود را تیک نزنید. وقتی به مرحله DC Promote رسیدید، گزینه add a Domain Controller to an existing Domain را انتخاب کنید.

dep conf

     در صفحه domain controller options باید گزینه Read Only Domain Controller (RoDC) را تیک بزنید. صفحه RoDC Options ظاهر میشود:

create rodc

     بصورت پیشفرض اطلاعات هیچ اکانتی روی RoDC ثبت و Cache نیمشود و در نتیجه هنگام logon کردن کاربران سایتی که RoDC برای آن ایجاد کرده اید، کماکان تمام درخواست های Logon جهت انجام عملیات AAA بسوی DC اصلی دامین یا یکی از writable Additional DC ها فرستاده میشود. ایین امر باعث افزایش استفاده از WAN link و کاهش پهنای باند، کاهش سرعت و کاهش کارایی شبکه ( بخصوص در سایت فیزیکی ) میگردد. پس مایکروسافت مکانیزمی را پینشهاد میکند که طی آن اکانتهایی روی RoDC ثبت cache شوند و از این پس هنگام logon اکانتهای فوق ، درخواست برای بررسی به DC فرستاده نشود و خود RoDC درخواست را بررسی کرده و تصمیم بگیرد. چنین اکانتهایی باید از سوی DC به RoDC مبادله ( Replicate ) شوند. حال در این صفحه میتوان مشخص کرد که پسوردهای چه نوع اکانت هایی از سوی DC به RoDC رپلیکیت شود. در حالت FULL additional DC پسورد تمام اکانت ها بین DC ها رپلیکیت میشود که ریسک امنیتی دارد. در کادرهای این صفحه میتوان اکانت های allowed و denied را مشخص کرد. ملاحظه میکنید که بصورت پیشفرض پسورد گروه RODC password Replication Allowed مجاز است که از DC اصلی به RoDC مبادله ( Replicate ) شود. اما مبادله پسوردهای اعضای گروههای ذیل بصورت پیشفرض غیر مجاز میباشد:

  • Administrators
  • Server Operators
  • Backup Operators
  • Denied RoDC Password Replication
  • Account Operators

    بهرحال از طریق دکمه های Add و Remove میتوانید همینجا گروههای مجاز و غیرمجاز جهت Replication را مشخص کنید و البته البته این تنظیمات بعدا هم قابل دستکاری هست. بهرحال چه در این صفحه و چه بعدا توصیه میشود که فقط اکانتهای متعلق به سایت فیزیکی فوق جهت Replication مجاز شمرده شوند. یعنی یا باید عضو گروه Allowed RODC password Replication  شوند یا از طریق دکمه Add و انتخاب گزینه  Allow به لیست اضافه شود. به صفحه بعد می رویم.

     در صفحه بعد چکباس install from media را تیک زده، محل فولدر IFM را معرفی کنید و در کادر پایین آن DC1 را جهت Replication انتخاب کنید. ( یا هر Writable Additional DC که مدنظرتان میباشد)

RoDC additional options

     در صفحه بعد هم محل ذخیره سازی دیتابیس اکتیودایرکتوری و فولدر sysvol را مشخص کنید:

ad ds files on DC3

     اکنون مراحل نصب را تا انتها ادامه دهید. وقتی کار خاتمه یابد دو DC در شبکه خواهیم داشت که قابلیت Fault tolerance و Load Balancing را به ما ارائه میکند. اکنون بهتر است که هر دو فولدر ifm موجود در دو DC را حذف کنیم.

     نکته مهم اینست که بعداز تبدیل کامپیوتر دوم به DC باید درآدرس Preferred DNS اش برابرآدرس خود یا 1270.0.1 شود وآدرس Alternative DNS اش برابر آدرس DC1 اول شود. در ضمن باید روی کارت شبکه کلیه کامپیوترهای مستقر در این سایت فیزیکی، آدرس DC3 بعنوان preferred DNS و آدرس DC1 بعنوان Alternative DNS وارد شود.

 

 

Password Replication

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

  • در اکتیودایرکتوری یک گروه میسازیم به عنوان RODC managers و کاربری نیز میسازیم به نام RODC و وی را عضو گروه فوق می کنیم.
  • حال در OU که به نام Domain Controllers وجود دارد وارد میشویم. ملاحظه میکنید که DC3 نیز بعنوان یکی از Domain Controller ها در آنجا وجود دارد و زیر ستون DC Type برای DC3 کلمات Read-only و GC نوشته شده است. GC مخفف Global Catalog است که در درسهای آینده با نقش و مفهوم آن آشنا خواهید شد.

DCs OU

  • حال وارد پنجره Properties متعلق به DC3 می شویم. در تب managed By گروه RODC managers را بعنوان مدیر سرور DC3و اعضای این گروه را از طریق تب managed by بعنوان مدیر کامپیوتر DC3 منصوب می کنیم. از این پس اعضای این گروه میتوانند روی DC3 دیوایس، درایور، update و hard Disk نصب کنند. AD DS را مدیریت کنند. Role و Feature نصب و مدیریت کنند. Event log ها را مشاهده نمایند و فولدرهای share شده و سرویس ها را مدیریت کنند.
  • سپس به تب Password Replication Policy می رویم و با شکل ذیل روبرو خواهیم شد. در اینجا نیز میتوان گروههایی را کم / زیاد کرد. توجه داشته باشید که چنانچه آبجکتی هم allow باشد و هم deny ، غلبه با deny خواهد بود.

Password replication Policy Tab

  • در اکتیودایرکتوری گروه هایی به نام allowed password replication و denied password replication وجود دارند. بد نیست بدانید که گروه Allowed Password Replication بصورت پیشفرض هیچ عضوی ندارد ولی در شکل ذیل میتوانید گروهها و کاربرانی که بصورت پیشفرض عضو گروه Denied Password Replication هستند ( و نباید در RoDC کش شوند) را مشاهده کنید:
  • Denied replication group
  • باری، در همین تب Password Replication Policy دکمه ای Advanced امکانات مهمی به ما میدهد. وقتی روی این دکمه کلیک کنیم با صفحه ای مانند شکل زیر روبرو خواهیم شد:

advanced settings in Password rep policy

     در تب Policy usage میتوان دو دسته اکانت ها را مشاهده کرد:

  • Accounts whose passwords are stored on this RODC : اکانت هایی ( شامل کامپیوترها، خود RODC ، یوزرها) که باید پسوردشان روی این RODC ذخیره و cache شود تا اگر ارتباط بین RODC و DC اصلی قطع شد، اینها بتوانند logon کنند. توجه داشته باشید که حتی کامپیوترها هم در اکتیودایرکتوری دارای پسورد هستند. اکانتهایی در اینجا cache خواهند شد که در وضعیت allowed replication باشند.
  • Accounts that have authenticated to this RODC : اکانت هایی که لااقل یکبار روی این RODC احراز هویت شده اند. مشاهده خواهید کرد که اگر اکانتی احراز هویت شد لزوما پسوردش cache نخواهد شد. بنابراین معمولا تعداد اکانت های گروه دوم بیشتر از اکانت های گروه اول است.

     حال، DC چه اکانتهایی را میتواند احراز هویت کند؟ اکانت هایی که در مد Allowed replication هستند. پس باید حتما کامپیوترهای شعبه فرعی در مد allowed replication ست شوند.

     برای درک اینکه این تنظیمات به چه دردی میخورند باید شرایطی مانند سناریوی ذیل را در نظر بگیرید:

     فرض کنید:

  1. کاربری در شعبه اصلی وجود دارد که مشغول کار هم هست.
  2. روزی این یوزر با Laptop شخصی به شعبه فرعی می آید که این شعبه دارای RODC است.
  3. این یوزر جزو اکانت های allowed replications نبوده است.
  4. اکنون وقتی در شعبه اصلی قصد لاگین داشته باشد، اطلاعات خود و لپتاپش از طریق RODC احراز هویت میشود. در واقع RODC این کار را به کمک DC انجام میدهد.
  5. اما فرض کنید زمانی که این کاربر قصد دارد در شعبه فرعی برای اولین بار لاگین کند، ارتباط DC و RODC قطع شده باشد.
  6. پسوردهای این کاربر و لپتاپش روی RODC طبعا cache نشده بوده است و امکان احراز هویت از طریق ارتباط RODC و DC نیز که وجود ندارد. یوزر فوق در logon به شبکه ناکام خواهد بود.
  7. برای رفع این مشکل، قبل از سفر آن یوزر باید روی DC شبکه وارد properties کامپیوتر RODC شعبه مورد نظر شویم و در تب password replication policy روی دکمه advanced و سپس روی دکمه prepopulate password کلیک کنیم. در اینجا باید اکانت یوزر فوق ( و نیز لپتاپش را) به RODC معرفی کنیم. در این صورت وقتی کاربر به شعبه برسد حتی اگر ارتباط هم قطع باشد، چون قبلا به RODC معرفی شده است، با اینکه سابقه logon به کامپیوترهای شعبه را ندارد و اطلاعاتش هم جایی cache نشده است، میتواند با لپتاپش( چون آن هم معرفی شده است) یا از طریق کامیپوترهای شعبه ( چون آنها cache شده اند- البته اگر سهل انگاری نکرده باشیم-) به شبکه logon کند.

 

 

Manual replication

      چه در حالت additional DC و چه در حالت RODC بهتر است همان ابتدا یکبار بصورت دستی عمل Replication انجام شود. با دستور repadmin /syncall در محیط cmd کامپیوتر DC اصلی شبکه.

 

 

نکات پایانی در بحث RODC

     با توجه به اینکه RODC در شعب ایجاد میشود و ما کاملا از وضعیت امنیت فیزیکی نمی توانیم مطمئن باشیم که چه افرادی و تحت چه شرایطی به Server room رفت و آمد دارند، بهتر است که RODC را روی بستر Virtual ایجاد کنیم و آن هارد فیزیکی که رویش ماشین مجازی RODC وجود دارد را با bitlocker  انکریپت کنیم که اگر هارد فوق به سرقت رفت، قابل استفاده نباشد. اکنون اگر کسی از RODC سواستفاده نماید، میتوانید سریعا متوجه شوید که پسورد کدام کاربران در معرض خطر قرار دارد. لذا پسورد این دسته از کاربران را ریست می کنید و نیازی به ریست پسورد همه کاربران نمی باشد.

     اگر در شبکه خود دارای چندین سایت فیزیکی هستید و در آنها RoDC ایجاد میکنید، در بحث Password Replication Policy بهتر است از گروه Allowd RODC Password Replication استفاده نکنید. چون اکانتهایی که برای یک سایت مجاز هستند با اکانتهای مجاز برای سایت دیگر متفاوت هستند. پس در چنین مواقعی برای هر RODC صراحت گروههای مجاز را Allow کنید و برای هر RODC گروه مخصوصی ایجاد نمایید.

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

مشاهده همه افزودن یک یادداشت
شما
دیدگاه خود را وارد کنید
رفتن به نوار ابزار