احمد جهلولی
متخصص سرویس های مایکروسافت

کاملترین آموزش ریکاوری اکتیودایرکتوری AD Forest Recovery

چگونه اکتیودایرکتوری را ریکاوری کنیم؟ فرآیند Recovery اکتیودایرکتوری چگونه انجام می شود؟ در این مقاله قصد دارم یک سناریو تعریف کنم و مراحل Recovery کردن Forest را بصورت عملی و تصویری به شما نشان دهم.کل سناریوی در تصویر زیر واضح و تعریف شدس :

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

Contoso.Local یک Parent Domain هستش و Itpro.Contoso.Local یک Child Domain که هر کدام از نقشها و عملکرد DC ها را در تصویر بالا مشخص کردم. توجه : حتما قبل از اینکه بقیه مطالب را بخوایند قسمت اول Forest Recovery که در بالا لینک آن را قرار دادم را بخوانید. ثانیا سناریو بالا را با دقت نگاه و درک کنید. قبل از اینکه فاجعه Failure در Forest من رخ دهد و کل شبکه را Down کند من یک Full Backup Backup از DC ها گرفتم. برای گرفتن Full Backup از لینک زیر کمک بگیرید :

https://technet.microsoft.com/en-us/library/cc771045

برای گرفتن System State Backup از لینک زیر کمک بگیرید:

https://technet.microsoft.com/en-us/library/cc772482 
  • نکته مهم : شما با گرفتن یک System State Backup قابلیت disaster recovery را ندارید یعنی اگر هارد یا منابع سخت افزاری از بین رفت نمی توانید AD را Recovery کنید.
  • نکته : System State Backup فقط بر روی همان سیستم عامل و همان سخت افزار قابل ریستور شدن می باشد.

بعد از گرفتن Backup از تمام Writeable DCهای ساختار یکی از اعضای تیم IT آن سازمان Exchangeی یا هر برنامه دیگری که Schema را تعقیر می دهد را اشتباه نصب کرد(بگذریم که چند بار این پروسه را انجام داد) و کل تعقیرات اشتباه در کل Forest توزیع شد. (این یک نمونه از چیزهای می باشد که می تواند کل Forest را تحت تاثیر و باعث Failure شود) الان نمی توانیم دوباره Exchange را نصب کنیم!!!!

عملیات Replication با خطا متوقف می شود!!!! هیچ کس نمی تواند Objectی در کل Forest ایجاد کند!!!! بهترین راه برای برگرداندن کل ساختار قبل از ایجاد این وضعیت, ریکاوری کردن کل Forest بوسیله Backup می باشد. شاید یکی به این نکته بدیهی اشاره کند که شما نیاز به ریکاوری کردن کل Forest ندارید فقط DCهای مشکل دار را Format کنید و دوباره OS and Active Directory نصب کنید و همه چیز بوسیله Replication به حالت اول بر می گردد!!!!

  • جواب: لازمه انجام کار بالا داشتن یک DC سالم که Schema آن تعقیر نکرده. که در سناریوی ما همه DCها درگیر این مشکل هستن.
  1. قبل از اینکه پروسه Recovery را اغاز کنم باید تعین کنم هر یک از DCها چه نقشی دارد؟؟؟؟؟
  2. اولین DC در هر Domain که قرار اولین DCی باشه که ریستور بشه را باید تعیین کرد؟؟؟
  3. Backup ی که قراره ریستور بشه را تعیین و ارزیابی بشه؟؟؟
  4. اولین DC را باید ایزوله کرد.

در مقاله اولی در رابطه با چهار ایتم بالا و پارامترهای که باعث انتخاب DCها و Backup می شود را کاملا توضیح دادم. اولین DC در ساختار که قبل از همه باید ریستور شود DCی در Forest root Domain می باشد. من در Forest root domain دوتا DC دارم که DC انتخابی DC-2 می باشد. چرا؟؟؟؟؟

چون DC-01 رولهای RID master and Schema را نگهداری می کند و ریستور کردن آن باعث اختلال در دیتابیس AD می شود. گرچه این روش توسط مایکروسافت توصیه نشده ولی اگر در مواقعی که فقط یک DC در سازمان دارید یکی از روشهای بازیابی کردن این دو رل بوسیله، Backup می باشد.! اولین قدم باید DC تعیین شده را ایزوله کرد که برای اینکار می توانید بقیه Writeable DCها را خاموش کنید یا کابل شبکه DC مورد نظر را بیرون بکشید یا Virtual network آن را تعقیر دهید یا غیرفعال کنید. بعد از تست و ارزیابی Backupهای گرفته شده من یک System State Backup برای ریستور کردن این DC در نظر گرفتم. در DC-02 در حالت DSRM بوت میکنم و دستور زیر را برای ریستور کردن System state Backup اجرا می کنم :

wbadmin start systemstaterecovery -version: 10/16/2015-14:20 –autsysvol
وب سایت توسینسو

با پارامتر –autsysvol همراه ریستور کردن System state بک آپ Authoritative resort Sysvol را نیز انجام می دهیم. دراقع با اجرای دستور بالا سه پارامتر مهم Forest Recovery بصورت اتوماتیک انجام می شود :

    1. System State Backup
    2. Authoritative Restore Sysvol
    3. Invalidating RID Pool
  • قدم دوم غیر فعال کردن Global Catalog می باشد برای اینکار :
وب سایت توسینسو
وب سایت توسینسو
  • قدم سوم باید FSMO بقیه DCهای Forest root domain را به این DC مصادره یا Seize کرد:

برای اینکار من از دستور :

Move-ADDirectoryServerOperationMasterRole

استفاده می کنم برای اطلاع بیشتر لینک زیر را بخوانید :

http://social.technet.microsoft.com/wiki/contents/articles/6736.move-transfering-or-seizing-fsmo-roles-with-ad-powershell-command-to-another-domain-controller.aspx

قبل از اینکار دستور netdom query FSMO را بر روی DC-02 اجرا می کنم ببینم چه رلهای روی این سرور میزبانی می شود :

وب سایت توسینسو

Schema Master and RID master بر روی DC-01 میزبانی می شود و باید این دو رل را Seize کرد. برای اینکار دستور زیر را اجرا می کنم :

Move-ADDirectoryServerOperationMasterRole -Identity "DC-02" –OperationMasterRole 1,3 –force
وب سایت توسینسو

بعد از آن با دستور netdom query FSMO چک کنید رلها Seize شدن.

  • قدم چهارم ایجاد یک کلید ریجستری برای جلوگیری از initial synchronization FSMO:

به مسیر زیر بروید و یک کلید با نوع Reg-Dword ومقدار 0 ایجاد کنید:

HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations
وب سایت توسینسو
  • قدم پنجم بالا بردن مقدار RID Pool می باشد :

برای اینکار شما دو روش دارید: روش اول در منوی RUN دستور Adsiedit.msc را وارد و اینتر کنید. در پنجره باز شده از منوی Action گذینه Connect to را انتخاب و به Default Naming Context وصل شوید :

وب سایت توسینسو

CN=System را انتخاب و بعد از آن CN=RID Manager$ را انتخاب کنید :

وب سایت توسینسو

از پنجره باز شده گذینه riDAvailablePool را انتخاب کنید و مقدار آن را کپی کنید :

وب سایت توسینسو

ماشین حساب سیستم را اجرا کنید و آن را در مد Scientific Mode ست کنید، مقدار بالا را در ماشین حساب کپی کنید و آن را با عدد 100000 جمع بزنید و حاصل آن را در کادر بالا (riDAvilablePool) کپی کنید و Apply و Ok کنید.

روش دوم دستور LDP.exe را در منوی RUN اجرا کنید : از منوی Connection گذینه Connect را کلیک کنید و بدون هیچ تنظیم خاصی Ok کنید، دوباره از منوی Connection گذینه Bind را انتخاب و با User ی که عضو Enterprise Admins باشد Login کنید.از منوی View گذینه Tree را کلیک کنید و بدون هیچ تنظیم خاصی Ok کنید. از سمت چپ گذینه CN=System,DC=<Domain Name> دابل کلیک کنید :

وب سایت توسینسو

از منوی باز شده گذینه CN=RID Manager$,CN=System,DC را انتخاب کنید :

وب سایت توسینسو

بر روی گذینه بالا راست کلیک کنید و Modify را کلیک کنید در فیلد Attribute متن rIDAvailablePool را وارد کنید و مقداری که در عکس بالا سمت راست صفحه مشخص کردم را دوباره با 100000 جمع بزنید و حاصل را در فیلد Values پست کنید. در قسمت Operations گذینه Replace را انتخاب کنید و Enter کنید. در آخر گذینه Synchronous را انتخاب کنید :

وب سایت توسینسو

الان دکمه RUN را کلیک کنید. خروجی دستور بالا باید شبیه متن زیر باشد:

***Call Modify... 
ldap_modify_s(ld, 'CN=RID Manager$,CN=System,DC=<Contoso>,DC=Local',[1] 
attrs); 
Modified "CN=RID Manager$,CN=System,DC=Contoso,DC=Local>".
  • قدم ششم Clean Up Metadata می باشد :

شما در این مرحله باید اطلاعات DCهای قبلی را از Metadataی این DC پاک کنید : برای این کار به کنسول Active Directory Users and Computers رفته و Computer Account های DCهای دیگر را پاک کنید :

وب سایت توسینسو

الان به کنسول Active Directory Sites and Services رفته و Objectهای دیگر DCها را پاک کنید.

  • نکته مهم : دست به Objectهای DCهای Child Domain نزنید.

الان به DNS بروید و NC وبقیه رکوردهای باقی مانده از DC-01 (دست به رکوردهای DC-03 که همون Child Domain ماست نزنید) را پاک کنید. در پروسه Metadata شما فقط DCهای Additional مربوط به یک Domain را پاک می کنید.

  • قدم هفتم تنظیمات DNS مربوط به همین سرور :

تنظیمات TCP/IP مربوط به DNS را بر روی IP همین سرور ست کنید :

وب سایت توسینسو
  • قدم هشتم ریست کردن Computer Account Password می باشد :

قبل از اینکار لینک زیر را مطالعه کنید :

https://support.microsoft.com/en-us/kb/325850

دستور زیر را دوبار بر روی سرور DC-02 اجرا می کنید و بعد از آن سرور را Restart می کنید :

netdom resetpwd /s:DC-02 /ud:Contoso.Local\Administrator /pd:*
وب سایت توسینسو
  • قدم نهم باید krbtgt password را ریست کنیم :

قبل از انجام اینکار اجازه بدید یک تعریف کلی از krbtgt Account بدم: اگر با کارکرد پروتکل Kerberos اشنائی دارید می دانید که هر User در ساختار دومین برای Login کردن به دومین و دسترسی به منابع باید یک Ticket با نام ticket-granting ticket (TGT) از Key Distribution Center که همان DC می باشد دریافت کند. قبل از اینکه Kerberos این کلید را تحویل User دهد این کلید را با پسورد krbtgt password رمزگذاری می کند.

وقتی Active Directory را نصب می کند این اکانت ایجاد می شود. خود اکانت krbtgt و پسورد آن بین همه DCهای دومین به اشتراک گذاشته می شود. برای ریست کردن krbtgt password مراحل زیر را انجام دهید : به کنسول Active Directory users and computers رفته و Advanced Features را از منوی View فعال کنید و به کانتینر Users رفته و بر روی krbtgt راست کلیک کنید و Rest Password را کلیک کنید و یک پسورد برای این اکانت ست کنید.

وب سایت توسینسو
    • نکته : مراحل بالا را دوبار انجام دهید.
    • نکته : نگران پسوردی که ست کردید نباشید چون این پسورد توسط DC بصورت اتوماتیک ایجاد می شود.

قدم دهم شما باید Trust Password بین Parent/Child Domain را Reset کنید:

اینکار برای Replicate شدن DCها با DCهای مجاز ساختار می باشد. و از Replicate شدن با Dcهای غیر مجاز جلوگیری می کند. (گرچه این پروسه در سناریو های دیگر شامل جزئیات بیشتری می باشد) برای اینکار دستور زیر را بر روی Parent Domain اجرا کنید :

netdom trust <parent domain name> /domain:<child domain name> /resetOneSide /passwordT:<password> /userO:administrator /passwordO:*
وب سایت توسینسو

نکته : مقدار PasswordT: باید بین Parent/Child domain یکی باشد. دستور زیر را بعد از ریکاوری کردن اولین DC در Child Domain اجرا می کنیم :

netdom trust <child domain name> /domain:<parent domain name> /resetOneSide /passwordT:<password> /userO:administrator /passwordO:*
وب سایت توسینسو
  • قدم یازدهم فعال کردن Global Catalog بر روی سرور DC-02 می باشد:
وب سایت توسینسو

کار ما در سرور DC-02 تمام شد. سرور را خاموش کنید.


الان به سراغ Domain های دیگر رفته عملیات بالا را بر روی DC انتخابی انجام دهید. قبل از اینکار به این چند نکته مهم توجه کنید:

  • برای ریستور کردن System state backup از پارامتر –authsysvol استفاده نکنید. (این پارامتر باید بر روی DCهای Forest root domain اجرا شود)
  • Global Catalog را بر روی DCهای غیر از Forest root domain غیرفعال کنید. ( بعد از ریکاوری کامل ساختار می توانید نقش GC را بر روی بقیه DCها فعال کرد)
  • فقط رلهای (FSMO) Domain-wide را بر روی DCهای غیر Forest root domain جابجا کنید. رلهای Forest-wide را دستکاری نکنید.
  • هنگام ریکاوری کردن DC های دومین های دیگر ساعت وتاریخ آنها را دستکاری نکنید.
  • وقتی Child Domainی را ریستور کردید Preferred DNS آن در با اولین DC ی ریستور شده در Forest Root Domain ست کنید.

بعد از انجام مراحل بالا الان شما باید در هر Domain یک DC ریکاور شده داشته باشید. DCهای ریکاور شده را از حالت ایزوله درآورید و به شبکه اصلی وصل کنید.

ساعت و تارخ همه DC ها را یکسان کنید.الان باید توسط دستور Repadmin.exe چک کنیم Replication بین DCهای ریکاور شده برقرار است یا نه؟

وب سایت توسینسو
وب سایت توسینسو

الان باید در Event Viewer دنبال Eventی به شماره ID: 4602 باشید. این Event مراحل موفقیت امیز DFS Replication مربوط به پوشه Sysvol در کل Forest می باشد.

وب سایت توسینسو

چک کنید که بتوانید به Resourceهای دومین های دیگر را فراخوانی و به آنها Permission دهید:

وب سایت توسینسو

در مرحله آخر یا دستور dcdiag.exe /v سلامت DC و DNS را چک کنید که Errorی دریافت نکنید.

بعد از اینکه مطمئن شدید DCها ریکاور شده با هم Replicate می کنند کلید رجیستری مربوط به initial synchronization FSMO را به 1 تعقیر دهید:

وب سایت توسینسو

سرورهای که پروسه بالا بر روی آنها انجام شده را Reset کنید و بعد از Reset وضعیت replication آنها را چک کنید.در این مرحله شما یک DC ریکاور شده در هر یک از دومین های Forest دارید که بصورت موفقیت امیز با هم در ارتباط هستن.در مرحله نهائی شما باید تمام Additional DC دومین های دیگر را به وسیله متد recovery active directory thought reinstall به مدار بر گردونید که پروسه راحت و اسانی هستش که برای طولانی نشدن مقاله می توانید به سایت زیر رجوع کنید :

https://technet.microsoft.com/en-us/library/cc816620(v=ws.10).aspx

بعد از اینکه کل Forest بصورت صحیح ریکاوری شد و هیچگونه مشکلی در ارتباط و Replication دومین کنترولرها مشاهده نشد می توانید رلهای FSMO را بین DCهای مناسب منتقل کرد یا نقش Global Catalog را در بین DCها فعال کرد.

منبع :

https://technet.microsoft.com/en-us/library/cc781218(v=ws.10).aspx

موفق و پیروز باشید

Backup گرفتن از ساختار Active Directory امری مهم و اجتناب ناپذیر می باشد. و مدیر شبکه باید احاطه کامل بر روی پروسه Backup and Restore در ساختار AD داشته باشد چون یک اتفاق یا انجام کاری اشتباه بر روی AD می تواند کل سازمان را تحت تاثیر بگذارد و باعث از دست دادن اطلاعات سازمان شود.کلا ما دو نوع سناریو ریکاوری در محیط Active Directory داریم :

  • Recovering a Single Domain within a Multidomain Forest
  • Recovering Your Active Directory Forest

در قسمتRecovering a Single Domain within a Multidomain Forest فقط یک DC در یک دومین از کار می افتد که پروسه ریکاوری آن بسیار ساده و سریع می باشد بدین صورت که رلهای FSMO که این DC نگهداری می کند را به بقیه DC ها منتقل می کنیم و Metadata آن را از بقیه DC ها پاک می کنیم و بوسیله متد recovery active directory thought reinstall آن DC را ریکاوری میکنیم.

ولی اگر کل Forest که شامل چندین سایت و چندین Domain که هر Domain دارای چندین DC باشد و کل این ساختار بصورت کلی صدمه دیده باشد این ساختار را چگونه Recovery کنیم؟؟؟؟قبل از اینکه به این سوال بپردازیم لینکهای زیر که مربوطه به Backup and Restore از Active Directory می باشد که توسط مهندس نصیری تهیه شده را بخوانید تا با دید بهتری بقیه مطالب را بخوانید.

ریکاوری کردن کل Forest شامل مراحل زیر می باشد :

  • شناسائی کردن مشکل : در اینمرحله شما باید به شناسائی مشکل و محدوده آن که باعث این معزل شده است بپردازید. از ابزارهای مانیتورینگ و Logهای Active Directory استفاده کنید. در بعضی از سناریوها Recovery کردن Forest بوسیله Backup آخرین گذینه برای اینکار می باشد.
  • تصمیم گیری درباره چگونگی ریکاوری کردن Forest : بعد از اینکه تعیین کردید آخرین گذینه برای Recovery استفاده از Backup می باشد باید ساختار Forest را تعیین کنید هر کدام از DCهای Forest چه عملکردی دارند، تعیین کردن اولین DC برای Restore در هر دومین، مطمئن شدن از خاموش بودن تمام Writeable DC ها در هنگام پروسه Restoring.
  • اقدمات اولیه برای Recovery : Restore کردن یک DC در هر Domain، پاک کردن Metadata بقیه DC، برگرداندن دوباره DC ها ریستور شده به مدار و ریست کردن کردن اکانتهای مدیریتی.
  • Deploy کردن DC های باقیمانده : بازگرداندن همه DCها به حالت قبل از Failure. این مرحله نیازمند یکسری پیشنیازها و طراحی دقیق می باشد. Clone گرفتن از Virtualization DC باعث تسریع در این پروسه می شود.
  • Clean Up : بعد از Recovery شدن کامل Forest باید تنظیمات آن فارست را به حالت قبل از Failure برگردانیم و یکسری تنظیمات تکمیلی در این مرحله انجام می شود.
وب سایت توسینسو
  • شناسائی کردن مشکل

هنگام Forest Failure شما باید از ابزارهای مانیتورینگ و Log های مورد نیاز دنبال علت این مشکل باشید و مشکلی که باعث ایجاد این Failure شده را تشخیص دهید.

مثالهای درباره علت Failure شدن Forest

    • به خطر انداختن ساختار AD بوسیله ناشی کاری ادمین شبکه. (ادمین های که با پارتی مدیر شبکه شدن همیشه این مشکل را دارند :) )
    • یکه حمله بین المللی یا اجرا شدن اسکریپتی که باعث خراب شدن دیتابیس AD شود.
    • یک حمله داخلی یا گسترش تعقیرات مضر و اشتباه در Schema.
    • یک هکر بد افزاری را روی DCها نصب می کند و باعث از دست رفتن یا خراب شدن دیتابیس AD میشود.
    • هیچکدام از DCها با Partner خود Replicate نمی کند.
    • تعقیرات بر روی DCها اعمال نمی شود.
    • عدم توانائی ایجاد یک DC جدید در ساختار.

تصمیم گیری درباره چگونگی ریکاوری کردن Forest

وقتی تصمیم گرفتید کل Forest را بوسیله Backup ریکاوری کنید، کل ساختار به حالت قبل از گرقتن Last Backup برمیگردد و در نتیجه :

  • تمام Object ها مانند User, Computer, Share folder که بعد از گرفته شدن Last Backup ایجاد شدند از بین می روند.
  • همه تعقیراتی که بعد از Last Backup بر روی Objectها صورت گرفته از بین می رود.
  • تمام تعقیراتی که بعد از Last Backup بر روی Configuration and Schema Partition ایجاد شده از بین می رود.

برای هر دومین در Forest باید پسورد Domain Admins Account در دست و شناخته شده باشد. (عدم فراموش کردن پسوردهای Admin زیرا این اکانتها برای ریکاوری DCها لازم می باشد) بصورت پیش فرض کاربر Built-in Administrator برای اینکار استفاده می شود و این اکانت نباید Disable باشد. همچنین برای Restore کردن DC شما نیاز به پسورد محیط DSRM دارید.

  • نکته : کاربری که پروسه Forest Recovery را انجام می دهد باید عضو گروهای زیر باشد :

• Enterprise Admins

• Domain Admins

که Built-in Administrator عضو این گروه ها می باشد.

چه Backup ی برای اینکار استفاده شود

توصیه شده برای هر دومین حداقل از دو Writeable DC بک آپ تهیه شود.

نکته: شما نمی توانید از Backup تهیه شده از RODC را بر روی Writeable DC ریستور کنید.

ریستور کردن System State Backup به سیستم عامل و سروری که قراره این Backup بر روی آن ریستور شود بستگی دارد.

برای مثال شما نباید System State Backup را بر روی سرور متفاوتی غیر از سروری که از آن Backup تهیه کرده اید ریستور کنید در غیر اینصورت با پیغام زیر رو به رو می شوید :

The specified backup is of a different server than the current one. We do not recommend performing a system state recovery with the backup to an alternate server because the server might become unusable. Are you sure you want to use this backup for recovering the current server?

اگر قصد دارید AD را بر روی سخت افزار مختلف یا جدید ریستور کنید باید یک Full Backup از آن سرور داشته باشید و برای ریستور کردن آن Plan مناسبی تهیه کنید.

  • نکته : Windows Server 2008 از ریستور کردن System State Backup بر روی یک OS جدید نصب شده یا سخت افزار جدید یا همان سخت افزار پشتیبانی نمی کند.

اگر سیستم عامل یک سرور بر روی همان سخت افزار Reinstall شده مایکروسافت توصیه می کند برای ریستور کردن آن مراحل زیر را به ترتیب انجام دهید :

  • • انجام Full Backup Restore به منظور بازیابی سیستم عامل و برنامه ها و فایلهای سرور
  • • انجام System State Restore و استفاده از ابزار Wbadmin.exe به منظور Authoritative کردن پوشه SYSVOL

برای اطلاع بیشتر لینک زیر را برای اینکار مطالعه کنید :

https://support.microsoft.com/en-us/kb/249694

نکته : Backupی که برای ریکاوری کردن DCها استفاده می شود باید طول عمر آن (LifeTime Backup) در بازه زمانی طول عمر deletedObjectLifetime and tombstoneLifetime باشد. برای اطلاع بیشتر درباره این دو خاصیت اینجا کلیک کنید.

  • انتخاب کردن اولین DC برای عملیات ریستور

پروسه ریستور کردن DCها باید به آسانی و با اطمینان انجام شود و این فاکتور مهمی برای انتخاب DCی هستش که باید این عمل بر روی آن انجام شود.مایکروسافت توصیه می کند یک DC اختصاصی برای اینکار در هر دومین مشخص شود.

توجه : حدالمکان رلهای RID Master and Schema Master را ریستور نکنید چون اینکار باعث ایجاد اختلال در دیتابیس AD می شود.

شرایطی که (بهتره) بر روی DC ی که قراره ریستور شود وجود داشته باشه :

  • • DC باید Writeable باشد. (اجباری)
  • • DC سیستم عامل Windows Server 2012 را اجرا کند و بصورت Virtualization باشد و از VM-Generation پشتیبانی کند. از این دی سی Clone گرفته ودر مواقعی که Restoring ناموفق باشد بتوان همه چیز را به حالت قبل برگرداند.
  • • DCی که بهترین Full Backup داشته باشد. بهترین Full Backup بک آپی می باشد که چند روز قبل از Failure گرفته شده باشد.
  • • DCی که قبل از Failure نقش DNS را در ساختار بازی می کرد. اگر چنین DC را ریستور کنید مجبور به نصب DNS و تنظیم آن نیستید.
  • • اگر از Windows Deployment Services در ساختار استفاده می کنید از DCی استفاده کنید که قابلیت Bit locker Network unlock بر روی آن تنظیم نشده باشد. این قابلیت نباید بر روی اولین DCی باشد که قراره ریستور شود.

تعیین کردن ساختار و عملکرد هر یک از DCها

یک لیست از تمام DCهای یک Domain ایجاد کنید مخصوصا DCهای که از آنها Backup گرفته شده و Virtualization DC های که می توان از آنها Clone گرفته شود. لیستی از تمام Forest Root Domain ایجاد کنید این لست اهمیت زیادی دارد چون عملیات restoring اول بر روی آنها انجام می شود.جدول زیر عملکرد هر یک از DC ها در Forest Root Domain مشخص می کند :

وب سایت توسینسو

نکته : اولین قدم در Forest Recovery انتخاب یک DC از لیست DCهای بالا می باشد. عملیات ریستور فقط بر روی یک DC انجام می شود و بقیه بوسیله متد recovery active directory thought reinstall به این DCها Join می شوند.

در مثال بالا چهار DC برای اینکار کاندید شداند

  • • DC-01
  • • DC-02
  • • DC-04
  • • DC-05

و DCی انتخابی DC-5 می باشد. به علت دلایل زیر:

  • • این DC یک VM می باشد که از VM-Genid را ساپورت می کند در نتیجه می توان از آن به عنوان ریسورسی برای Clone گرفتن استفاده کرد.
  • • یک DNS سرور می باشد که با Restoring کردن آن DNS و Name Space ساختار هم ریستور می شود.
  • • یک Full Installation می باشد که نسبت به Core Installation پروسه ریستور کردن آن راحت و با اطمینان می باشد.
  • • FSMO مهمی را نگهداری نمی کند. پس به راحتی تمام FSMO رلها را به این DC مصادره یا Seize کرد.

یکی از مزیتهای انتخاب DC-5 فعال نبودن Global Catalog بر روی این سرور می باشد. که مجبور نیستیم بعد از ریستور کردن GC را حذف کنیم. این مسئله در Windows Server 2012 اهمیت چندانی ندارد چون بصورت پیش فرض تمام Dc ها رل GC را بازی می کنند که حذف و اضافه کردن GC بعد از ریستور کردن در تمام سناریوها توصیه شده است.

  • ریکاوری کردن forest در یک محیط ایزوله شده

مایکروسافت توصیه می کند قبل از ریستور کردن اولین DC بقیه Writeable DC ها را خاموش کنید یا کابل شبکه DC ی که قراره ریستور شود بیرون کشیده شود تا در حین ریستور اطلاعات خراب و مضر به بقیه DCها Replicate نشود.( فرض کنید Backupی داریم که علاه بر اطلاعات AD شامل ویروس یا اطلاعات مضری باشد که با ایزوله کردن DC این اطلاعات بر روی بقیه DC ها Replicate نشود).ثانیا وقتی کاربران ادمین را ریست می کنیم یا عملیات Clean up metadata را انجام دهیم وقتی این DC با بقیه در ارتباط باشد این عملیات ناممکن می باشد.

اقدامات اولیه برای ریکاور کردن Forest

  • ریستور کردن اولین DC در هر دومین :

Forest Root Domain از بقیه دومین ها اهمیتن زیادی دارد چون این دومین دو گروه مهم Schema Admins and Enterprise Admins را نگهداری می کند. بعلاوه Forest Root Domain سلسله نام گذاری کل Forest را نگهداری می کند و DNS سرور در این دومین A record کل DCهای Forest و رکوردهای Global Catalog را نگهداری می کند که برای پروسه Replication حیاتی و لازم است.وقتی که Forest root domain را ریکاوری کرده اید می توانید بقیه Domain ها را نیز ریکاوری کنید.

توجه : همیشه Parent Domain را قبل از Child Domain ریکاوری کنید. به علت Trust hierarchy یا Name Resolution.

بعد از اینکه کارهای اولیه را انجام دادید و نکات و توصیه ها را رعایت کردیم نوبیت به انجام مراحل اولیه ریکاوری می رسد:

  1. DC مورد نظر را ایزوله کنید.
  2. بخاطر اینکه اولین Writeable DC می باشد باید یک Nonauthoritative Restore انجام دهیم و بعد از آن پوشه SYSVOL را Authoritative Restore می کنیم. برای ریستور کردن Backup مورد نظر باید از ابزارهای که VSS را پشتیبانی می کنند استفاده کنیم. مانند Windows Server Backup or Backup Exec و غیره. نکته : Authoritative Restore کردن پوشه SYSVOL یکی از مراحل مهم بعد از ریستور کردن dc می باشد چون بعد از ریستور کردن DC این پوشه باید بر روی بقیه DCها Replicate شود و DCهای دیگر پوشه SYSVOL خود را بر اساس این پوشه سینک می کنند. توجه داشته باشید Authoritative Restore کردن پوشه SYSVOL فقط مختص به اولین DCی می باشد که در Forest Root Domain ریستور می شود. انجام این پروسه بر روی بقیه DCها باعث ایجاد اختلال در Replication می شود.
  3. بعد از ریستور DC را Restart کنید و برسی کنید که تمام اجزای AD سالم و بصورت صحیح کار می کنند. اگر باز هم شاهد خراب بودن دیتابیس واجزای دیگر AD شده اید به مرحله 2 برگردید و DC را با یک Backup دیگر ریستور کنید. (اینجاست که Clone گرفتن از DC به درد شما می خوره)

نکته : اگر DCی که ریستور کرده اید رلهای FSMO را میزبانی می کند باید کلید رجیستری زیر را ایجاد کنید تا DC از دسترسی خارج نشود و با بقیه DCها Replicate کند :

HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations

کلیدی با نوع Reg-Dword ومقدار 0 ایجاد کنید. بعد از اینکه کل Forest ریکاوری شد این مقدار را به 1 تعقیر دهید.

سوال ؟؟؟

چرا ما باید این کلید رجیستری را ایجاد کنیم؟؟؟وقتی AD استارت می خورد قبل از اینکه با همه DC ها عملیات Replicate را انجام دهد در مرحله اول با همه DCهای که هر یک از رلهای FSMO را نگهداری می کند Replicate می کند تا از آخرین وضعیت FSMO باخبر شود و مطمئن شود هر کدام از رلها بر روی کدام DC قرار دارد. این پروسه قبل از هر گونه Replication باید انجام شود. ما با ایجاد این رجیستری initial synchronization FSMO را کنسل می کنیم و به DC می گویم این پروسه را بیخیال شو.برای اطلاعات بیشتر لینک زیر را مطالعه کنید :

https://support.microsoft.com/en-us/kb/305476

در صورتی به مرحله بعد بروید که مطمئن باشید DC ها بصورت صحیح ریستور وتمام اجزای آن بصورت صحیح و بدون نقص کار میکنند.

  1. اگر علت Failure شدن Forest یک حمله داخلی یا خارجی باشد در این مرحله باید پسورد اعضای گروهای زیر را ریست کنید :
  • • Enterprise Admins
  • • Domain Admins
  • • Schema Admins
  • • Server Operators
  • • Account operators
  1. در این مرحله تمام FSMO رلها را به DC ریستور شده Seize کنید. در Forest root domain علاوه بر رلهای Domain-wide باید رلهای Forest-wide را هم به DC مورد نظر مصادره یا Seize کنید.
  2. Metadata بقیه DC ها را از این DC پاک کنید. پاک کردن Metadata باعث جلوگیری از ایجاد Duplication of NTDS-setting و همچنین باعث جلوگیری از کار افتادن (یا نجات) پروسه KCC می شود.

توجه : اگر این DC قبل از Recovery نقش RID master را بازی می کرد و ما بعد از ریکاوری Metadata را پاک نکنیم این DC قادر به ایجاد RID Pool جدید نمی باشد برای چنین وضعیتی سیسیتم Logی با شماره ایدی 16650 ثبت می کند، ولی بعد از پاک کردن Metadata سیستم Logی به شماره ایدی 16648 در Even Viewer ثبت می کند که نشان دهنده رفع مشکل بالا می باشد.

  1. در این مرحله باید مطمئن شوید DNS بر روی این DC نصب و Config شده است در غیر اینصورت شما باید DNS را نصب و کانفیگ کنید.

نکته : بعد از ریستور کردن یکی از DCهای Forest root domain آن DC را با IP خود (own IP) یا Loopback Address را در قسمت Preferred DNS تنظیم کنید.

نکته : در –msdcs and Domain zone هر NS رکوردی که به DCهای Offline تعلق دارد را بعد از پروسه Clean up metadata پاک کنید. مطمئن شوید رکورد SRV بقیه دومین ها پاک شده است (بعد از Clean up metadata این رکوردها بصورت اتوماتیک پاک خواهند شد)

برای پاک کردن مطمئن و سریع SRV رکوردها دستور زیر را اجرا کنید:

nltest.exe /dsderegdns:server.domain.tld
  1. 2. در این مرحله باید مقدار Available RID Pool را افزایش دهید.

سوال؟؟

چرا ما باید RID Pool را افزایش دهیم؟؟؟

فرض کنید بعد از گرفتن Backup ما یک Security Principles (SID) جدید برای کاربری ایجاد کردیم و این Security Principles مجوزهای بر روی منابع خاصی دارد، بعد از ریکاوری Security Principles از بین می رود ولی مجوزها (Access Right) آن باقی می ماند، در نتیجه اگر RID Pool را بعد از ریکاوری افزایش ندهیم ممکن است همین Access Right ها بعد از ریکاوری به Object دیگری واگذار شود در حالی آن Object مجاز به استفاده آن منابع نمی باشد.

مثال زیر شما را در فهم این پروسه کمک می کند :

To illustrate, consider the example of the new employee named Amy that was mentioned in the introduction. The user object for Amy no longer exists after the restore operation because it was created after the backup that was used to restore the domain. However, any access rights that were assigned to that user object might persist after the restore operation. If the SID for that user object is reassigned to a new object after the restore operation, the new object would obtain those access rights.

  1. Invalidate کردن RID Pool جاری، بصورت پیش فرض وقتی یک System State Restore انجام دهید این پروسه اتفاق می افتد در غیر اینصورت شما باید این پروسه را دستی انجام دهید. این پروسه باعث میشه DCی که نقش RID Master را بازی می کند یک RID Pool جدید به دومین ها اختصاص داده بشه و باعث جلوگیری از Duplicate شدن RID در بین Objectها می شود.

نکته : بعد از این عمل اگر Objectی در AD ایجاد کردید یکخطا دریافت می کنید ولی در دفعات بعد مشکل حل می شود.

• Computer Account Password سرور DC را دوبار ریست کنید.

• KRBTGT Password را دوبار ریست کنید.

• اگر فارست شامل چندین Domain باشد و DCی که ریستور کرده اید قبلا نقش Global Catalog را بازی می کرد باید GC بعد از ریستور غیرفعال شود و دوباره فعال شود.

نکته : اگر Forest شما فقط یک Domain داشته باشد نیاز به این کار نیست.

سوال می پرسم :

چرا ما باید اینکار را انجام دهیم؟ اگر انجام ندهیم چه اتفاقی می افتد؟؟

خودتون جواب بدید. جواب خود را در بخش نظرات ارسال کنید.

• Windows Time را در این DC تنظیم کنید.

بعد از انجام مراحل بالا DC را Restart کنید و به شبکه وصل کنید.

در این مرحله از عملیات Forest Recovery شما در هر Domain یک DC ریستور شده دارید.

تسکهای زیر را برای بهبود Replication بین DCهای ریستور شده انجام دهید.

• DNS Delegation Record را ایجاد کنید. همچنین DNS Forwarding و در صورت نیاز Root hints را هم تنظیم کنید. دستور Repadmin.exe /replsum را اجرا کنید. این دستور وضعیت Replication را بین DC ها را چک می کند.

• برای Validate کردن metadata دستور repadmin /viewlist* برای تمام DCهای Forest اجرا کنید.

• برای چک کردن DNS های ساختار از دستور DCdiag /v را اجرا کنید تا گزارشی کاملی از تمام Errorهای Forest به شما نشان دهد.

اضافه کردن GC بر روی یکی از DCهای Forest root domain :

شما به خاطر دلایل زیر نیازمند یک GC در ساختار می باشید :

• برای Login کردن کاربران.

• سرویس Net logon که بر روی Child domain می باشد را قادر می سازد که خود را در DNSهای Forest root domain رجیستر کنند وبتوانند رکوردها را در DNS پاک کنند.

نکته : مایکروسافت توصیه می کند Forest root DC نقش GC را بازی کند.

توجه : DC تا زمانی که خود را با کل Directory Partitionهای Forest سینک نکند نمی تواند نقش GC را بازی کند. بنابراین شما باید DC را Force کنید با همه DC های ریستور شده Replicate کند.

برای اینکه مطمئن شوید DC نقش GC را بازی می کند شماره ایدی 1119 را در Event Viewer چک کنید.

در این مرحله در هر یک از دومینهای Forest یک DC ریستور شده و یک GC در کل Forest وجود دارد. توصیه شده در این مرحله از تمام DCهای ریستور شده یک Backup تهیه شود. از این به بعد می توانید بقیه DC های Forest را بوسیله Reinstall کردن اکتیودایرکتوری Deploy کنید.

  • Deploy کردن DCهای باقی مانده

این مرحله بستگی به محیط و دیزان ساختاری سازمان شما دارد.اولین قدم در این مرحله نصب AD بر روی DCهای باقیمانده می باشد. اگر AD و تنظیمات آن از قبل وجود داشت باید آن را بصورت اجباری پاک یا از متد recovery active directory thought reinstall استفاده کنید.

  • نکته : به هیچ وجه Backupهای این DCها را ریستور نکنید چون باعث اختلال در ساختار می شود.

شما می توانید از دو متد زیر برای نصب Additional DC استفاده کنید :

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

• Reinstall کردن AD بوسیله Windows Power Shell می باشد. در ورژن های قدیمی می توانید از متد recovery active directory thought reinstall استفاده کنید.

نکته : اگر DCها در مناطق جغرافیای مختلفی باشند برای کاهش میزان ترافیک Replicate از قابلیت Install From Media (IFM) استفاده کنید.

  • Clean Up

بعد از آنکه کل Forest ریکاوری شد باید تنظیمات DNS دی سی ها را انجام داد ومثل قبل (قبل از Failure) تنظیمات Preferred و Alternate قسمت DNS دی سی ها را بصورت صحیح انجام داد .

  • پاک کردن هر گونه رکوردی که متعلق به DCی می باشد که هنوز ریکاوری نشده است.
  • تمام رکوردهای Wins سرور مربوط به DCهای که ریستور نشده اند یا از مدار خارج شده اند را پاک کنید.
  • می توانید FSMO رلها را بین DC های مختلف یک دومین توزیع کنید. یا GC بیشتری در ساختار فعال کنید.
  • تمام Objectهای که بعد از Last Backup ایجاد شده اند را دوباره ایجاد کنید
  • رجیستری مربوط به FSMO Replication را به مقدار 1 برگردانید.

در قسمت دوم از همین مقاله یک سناریو تعریف می کنم و پروسه Forest Recovery را بصورت عملی به شما نشان می دهم.

منبع :

https://technet.microsoft.com/en-us/library/cc757662(v=ws.10).aspx

موفق و پیروز باشید


احمد جهلولی
احمد جهلولی

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

سایت شخصی من: https://msdeeplearn.net

نظرات