انتقال اشیاء بین دامین ها و جنگل ها – مباحث تئوری

در سناریو های چند دامینی عمل انتقال اشیاء بین دامین ها و جنگل ها بسیار صورت می گیرد. ممکن است حجم قابل توجهی از کاربران، گروه ها و کامپیوتر لازم باشد تا انتقال یابند. به دامینی که اشیاء از آن منتقل می شوند Source Domain و به دامین مقصد، Target Domain می گوییم. بر حسب وضعیت قرار گیری جنگل در عمل انتقال، انتقال به دو دسته تقسیم می شود:

۱) Infra-Forest Migration : انتقال اکانت ها و بازسازی درون یک جنگل
۲) Inter-Forest Migration : انتقال اکانت و بازسازی بین جنگل متمایز با جنگل Source Domain

در Inter-Forest Migration کپی از نسخه اکانت ها روی Target Domain ایجاد می شود و اکانت های روی Source Domain از بین نمی روند. این مکانیسم سبب می شود تا بتوان عمل انتقال را در چند فاز کاری مختلف انجام داد. پس از پایان عملیات انتقال و بازسازی ساختار Target Domain به سادگی می توان Source Domian را آفلاین کرد. در Infra-Forest Migration تنها با انتقال مستقیم از Source Domain به Target Domain انجام می شود و پس پایان عمل انتقال می توان ساختار را بازسازی کرد و OU  های جدید مورد نیاز را ایجاد کرد. سازمان ها که از ساختار دامین های چند تایی استفاده کرده اند از این روش برای انتقال به یک دامین جهت کاهش هزینه ها استفاده می کنند.

آشنایی با ابزار Active Directory Migration Tool

ابزار Active Directory Migratin Tools V3.1 می تواند اشیاء را میان Source Domain به Target Domain  منتقل کند. ADMT یک ویزارد برای انتقال کاربران، گروه ها، کامپیوتر ها، Trust ها و اکانت های سرویس را در اختیار شما قرار می دهد. همچنین می توان با استفاده از کنسول ADMT یا خط فرمان این کار را انجام داد. ADMT بسیار قدرتمند است و راه های مختلقی برای اتوماتیک کردن فرآیند وجود دارد. AMDT همچنین می توان با استفاده از VBScript یک اسکریپت تهیه و عملیاتMigration را انجام داد. همچنین ADMT امکان شبیه سازی را فرآهم می آورد که به این طریق می توان احتمال بروز خطا ها را بدون هیچ تغییر ارزیابی کرد. همچنین ویزارد این امکان را می دهد که پس از ارزیابی، انتقال را به زمان دیگری موکول کنید و به رفع خطاهای ارزیابی شده بپردازید. اکیدا توصیه می شود پس از رفع خطاهای ارزیابی شده، مجدد عملیات انتقال را ارزیابی کنید. این ابزار قابل دریافت از وب سایت مایکروسافت است و ورژن ۳٫۱ آن از ویندوز سرور ۲۰۰۸ پشتیبانی می کند.

Security Identifiers و انتقال

پیش از انجام عمل انتقال لازم است تا بر SIDs مسلط بود. همچنین لازم است با مفاهیم Token، Access Control List و SIDHistory آشنا بود.

SID معرف هایی برای اشیا در دامین هستند که در تمام دامین یکتا هستند. مثلا در زمان ساخت یک کاربر، یک SID به آن تعلق می گیرد و زمانی که کاربر Logon می کند یک Token جهت دسترسی برای او صادر می شود که شامل SID کاربر است. همچنین آن Token شامل SID های گروه هایی که کاربر عضو آن ها است.منابع با استفاده از SD یا Security Descrptor ایمن می شوند. SD می تواند مجوز ها، مالکیت و Auditing (بازبینی) را برای معین کند. در SD در واقع دو ACL وجود دارد. Discretionary ACL که در واقع سطوح دسترسی به منبع را معین می کند. به Discretionary ACL به اختصار DACL گفته می شود. معمولا بسیاری از منابع آموزشی به جای استفاده از واژه DACL به اختصار از ACL استفاده می کنند. ACL دیگری که در SD موجود است System ACL یا SACL است که معرف Auditing روی آن منبع است. در DACL لیستی از اشخاصی که دارای دسترسی به منبع هستند وجود دارد که به هر کدام از آن ها ACE گفته می شود. ACE می تواند Allow یا Deny باشد. از آنجا که DACL مستقیما به SID کاربر مربوط است سطوح دسترسی کاربر به هر منبع از طریق SID خود و SD منبع صورت می گیرد. زمانی که کاربر تلاش می کند به یک منبع دسترسی پیدا کند، LSASS یا Local Security Authority Subsystem ابتدا SID کاربر را که در Token او موجود است با SID های موجود در DACL مقایسه می کند و سپس در صورت مجوز Allow به او مجوز استفاده از منبع را می دهد.

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

۱) SIDHistory: معمولا مدیران شبکه دوست دارند از SIDHistory برای کارآمد کردن بازسازی ساختار اکتیو دایرکتوری استفاده کنند. در یک Attribute به نام SIDHistory می توان SID های اکانت را ذخیره کرد و LSASS مشابه یک SID عادی با آن برخورد می کند و همچنان SID اکانت در دامین یکتا است.

۲) Security Translation: فرآیندی است که طی آن SD های منابع با SID های Source Domain مقایسه می شوند و با SID ی Target Domain جایگذاری می شوند. به فرآیند باز ارتباط دهی SID ها RE-ACLing نیز گفته می شود. بدیهی است که انجام این فرآیند به صورت دستی خسته کننده و یا اصلا غیر ممکن است. ADMT می تواند این کار را به صورت خودکار انجام دهد. ADMT می تواند در خصوص موارد زیر Security Translation را به خوبی انجام دهد:

آ: File & Folder Permissions
ب: Printer Permissions
ج: Share Permissions
د: Registry Permissions
ه: User Rights
و: Local Profile که شامل تغییر مجوز های دسترسی فایل ها و پوشه ها نیز می شود.
ز: Group Membership

نکته مهم: فرآیند انتقال معمولا مدتی طول می کشد. از این جهت توصیه می شود از SIDHistory در زمان فرآیند انتقال استفاده کنید و سپس از Security Translation در پایان فرآیند استفاده کنید.

عضویت در گروه ها

آخرین نگرانی بزرگ در عمل انتقال برای دسترسی به منابع تغییرات در عضویت ها هستند. گروه های Global تنها می توانند از همان دامین عضو داشته باشند. بنابراین اگر یک کاربر به Target Domain کپی شود دیگر نمی تواند عضو آن گروه باشد. در Inter-Forest Migration برای حل این مشکل لازم است ابتدا Global Group ها به Target Domain را انتقال دهید. این گروه ها با استفاده از SIDHistory می توانند SID خود را نگه دارند و سپس انتقال کاربران را آغاز کنید. ADMT می تواند کاربر را در Target Domain دوباره عضو همان گروه کند. اگر گروه در Target Domain وجود نداشته باشد ADMT می تواند یک گروه جدید در Target Domain بسازد. در نهایت؛ کاربر در Target Domain به عضویت آن گروه در خواهد آمد و کاربر و گروه در SIDHistory خود دارای SID پیشین خود در Source Domain هستند و تغییر در دسترسی آن ها صورت نمی گیرد.

در Ifra-Domain Migration فرآیند با آنچه برای Inter-Forest Migration گفته شد متفاوت است. ابتدا گروه Global در Target Domainبه عنوان گروه Universal ساخته می شود. بنابراین می تواند شامل کاربرانی از هر دو دامین Source و Target باشد. گروه Universal جدید SID جدید می گیرد اما در SIDHistory خود SID گروه Global روی Source Domain را نگه داری می کند. پس از آنکه عمل انتقال کامل شد، Group Scope از universal به global تغییر می کند.

سایر نگرانی ها و راهکار ها

نگرانی های متعددی در عملیات انتقال موجود است. در اینجا به اختصار به سه مورد دیگر که قابل توجه هستند اشاره می شود:

۱) انتقال کلمه های عبور: ADMT می تواند کلمه های عبور را بدون توجه به سیاست های Target Domain منتقل کند. به عنوان مثال یک کلمه عبور خالی منتقل می شود. کلمه عبور جدید فعال خواهد ماند تا در زمان Expire شدن کاربر مجبور باشد با شرایط دامین جدید کلمه عبور انتخاب کند.

۲) اکانت های سرویس: سرویس های روی کامپیوترها ممکن است از اکانت های دامین استفاده کنند. از آنجا که SID های این اکانت ها تغییر می کند ADMT به صورت خودکار اطلاعات سرویس را به روز می کند.

۳) اشیائی که نمی توانند منتقل شوند: با آنکه ADMT ابزار قدرتمندی است دارای محدودیت هایی نیز هست. به عنوان مثال ADMT نمی تواند گروه های پیش ساخته یا Built-in را منتقل کند.

بهترین شیوه انجام یک سناریو ی انتقال

۱) تهیه نسخه پشتیان به صورت کامل از Source Domain و Target Domain. همچنین اگر کامپیوتر هایی وجود دارند که در انتقال وجود دارند و روی آن ها به اشتراک گذاری منابع صورت گرفته و از Security Translation استفاده می شود توصیه می شود از آن ها نیز Backup گرفته شود.

۲) ساخت یک کاربر آزمایشی و عضویت آن در یک گروه مناسب و انجام عملیات انتقال به صورت آزمایشی و در نهایت چک کردن دسترسی ها.

۳) آزمایش سناریوی انتقال در یک محیط آزمایشی پیش از انتقال در محیط عملیاتی

۴) برنامه ریزی برای Recovery و کسب اطمینان از آنکه برنامه Recovery کارا و صحیح است.

۵) رمزگشایی کردن (Decrypt) فایل های رمزنگاری شده (Encrypted) توسط EFS و کسب اطمینان جهت اطلاع کاربران از این امر.

۶) کسب اطمینان از آنکه زمان کامپیوتر ها با هم Sync است. زیرا Kerberos در صورت اختلاف از تشخیص هویت باز می ماند.

۷) انجام عملیات انتقال