آشنایی با اکتیو دایرکتوری Active Directory(بخش دوم)

برای مطالعه بخش اول لطفا اینجا کیلیک کنید.

 – هرچیزی که در دیتابیس Active Directory ذخیره میشود یک Object است. یعنی وقتی که یک User میسازید یک Object ساختید، وقتی یک گروه میسازید یک Object ذخیره کردید و به همین ترتیب.

در بخش اول  در مورد بخش های مختلف Logical اکتیو دایرکتوری صحبت کردیم، همانطور که به یاد دارید یکی از مزایایی که در Active Directory دارید SSO است. یعنی یک User وقتی داخل دومین لاگین میکرد از اکتیو دایرکتوری Ticket دریافت میکند و از آن به بعد داخل هر Resource ای که داخل آن دومین است اگر بخواهد متصل شود Ticket  را نشان میدهد و احتیاجی به احراز هویت مجدد نیست. اما گفتیم مقوله تیکت گرفتن و نشان دادن آن فقط در محدوده ی آن دومین است. اگر یک User  بخواهد از دومین A به دومین B متصل شود تیکتش قابل قبول نیست، مگر اینکه بین آن ها Trust برقرار شود. در این شرایط تیکت یک دومین میتواند در یک دومین دیگر مورد قبول قرار بگیرد. سپس انواع Trust ها را تعریف کردیم.

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

اولین دومین راه انداز فارست جدید را Root Forest میگویند. همچنین اسم دومین Root Forest اسم کل فارست میشود. حالا این فارست میتواند یک سری Child داشته باشد و همچنین میتواند Root Tree داشته باشد. اگر به یاد داشته باشید گفته بودیم که چه شرایطی باید پیش بیاید که بخواهیم یک دومین جداگانه داشته باشیم؟ که در پاسخ گفتیم بحث، بحث Isolation است. یعنی شما میخواهید یک سری از User ها در یک دومین جداگانه با یک مدیریت کاملا مجزا باشند و یک سری کامپیوتر هم در یک دومین دیگر باشند با یک مدیریت مجزای دیگر و نمیخواهیم آن ها را در یک دومین دسته بندی کنیم چرا که اگر در یک دومین دسته بندی شوند یک مدیریت به آنها اعمال میشود. گفتیم  دومین میتواند Chid یا Parent باشد که اگر Parent باشد به آن میگویند Root Tree.

همانطور که قبلا گفتیم اسم دیتابیس اکتیو دایرکتوری NTDS.DIT است. ما در داخل این دیتابیس یک سری پارتیشن داریم (اینکه میگوییم طبقه بندی شده اند منظور همین پارتیشن ها است). در هریک از این پارتیشن ها هم میتوانیم یک سری اطلاعات ذخیره کنیم. NTDS.DIT پارتیشنی به نام Schema. Schema و به معنای الگو یا مدل دارد. در اکتیو دایرکتوری شما میخواهید Object درست کنید، مثلا Object که User. این ابجکت User باید یک الگوی ساخت داشته باشد. در Schema الگوی ساخت Object ها قرار گرفته است. یعنی اگر قرار شد مثلا User Object درست کنیم این را بر چه اساسی درست کنیم و الگوی ساخت آن چیست؟ حالا در زمان ساخت یک Object یک سری Attribute ها و المان هایی مورد نیاز هست. یک Object برای اینکه درست شود باید دید که از چه عناصری درست شود. بعد این عناصر را چگونه باید در کنار هم جمع بکنیم که  ان object شود. پس الگوی ساخت و تمام اون المان ها و Attribute ها میشود Schema. Schema دیتابیسی است که Attribute های مورد نیاز جهت ساخت Object و الگوهای ایجاد Object را در خودش نگه داری میکند. یعنی یک User بسازید کامپیوتر باید  Schema را نگاه کند و ببیند فرآیند ساخت User چگونه است و چه Attribute هایی را باید با هم جمع کنیم که User به وجود آید. این Data ها را از Schema میخواند. این Schema قابل اضافه شدن است (Schema ، Read Only است زیرا چیزهایی که در Schema هست قابل Delete شدن نیست) و المان های جدید اضافه کرد اما برای این کار باید کد زد و اسکریپت نوشت.

• تمامی DC ها یک کپی از Schema را در خودشان دارند.

Schema در کل فارست Global است. یعنی Root Forest که اولین بار راه اندازی شده Schema را به وجود می آورد. تمامی دومین های دیگری که در این فارست راه اندازی میشوند یک کپی از Schema ای که Root Forest درست کرده است را در خودشان دارند. پس اگر الگوی ساختی در Schema به وجود آید یا اینکه تغییراتی در لیست Attribute ها به وجود آید این تغییرات به صورت Globally در کل Domain های Forest اعمال میشود. هر دومین برای خودش Schema مجزا ندارد.

Domain ها از Object هایی که در Domain های دیگر است اطلاعی ندارند چون کاملا مجزا هستند. فقط این DC های یک دومین هستند که میدانند چه Object هایی در آن دومین وجود دارد. حال آیا این امکان وجود دارد که شما بخواهید یک Search در کل فارست بزنید و بگویید تمامی Object های User ای که Firstname آنها مثلا Ali هست را میخواهم ببینم؟ بله. حالا این کار را باید کجا انجام دهیم؟ اگر از یک DC بپرسیم آن DC فقط از Object های دومین خودش خبر دارد. پس تا اینجا یک راه این است که  در تک تک دومین ها Search (یعنی به تعداد دومین ها باید Search انجام دهیم)کنیم. . اما این اشکال دارد زیرا باید کارتکراری انجام دهیم. پس بهتر است که یک مرجع و سرویسی وجود داشته باشد که اطلاعات در مورد کل فارست را داشته باشد و بتوانیم Search ها را از آن بزنیم. به این ترتیب در یک فارست فقط یکبار Search میکنیم.

در اکتیو دایرکتوری یک سرویس  به نام Global Catalog یا به اختصار GC داریم.

GC یک مجموعه از تمام Attribute های Searchable ئه Object های کل دومین های Forest را در خودش نگه داری میکند.

یک Object از یک سری Attribute تشکیل شده است، یک سری از این Attribute ها   قابل Search هستند. برای مثال روی User چه Attribute هایی میتواند قابل Search باشد؟ Firstname، Lastname، Email، شماره ی تلفن و … . یک سری Attribute هم وجود دارد که قابل Search نیستند. برای مثال ما هیچ وقت روی SID یک User جستجو انجام نمیدهیم. پس ما به جای اینکه چندین بار در دومین ها Search کنیم یکبار در GC، Search میکنیم. بنابراین Global Catalog، Indexing ای جهت Search در کل فارست است. 40 تا 60 درصد Attribute های یک Object، Searchable است. پس این Attribute ها داخل GC هستند.

   – سوال اینجاست که آیا Forest بدون GC معنی  دارد؟ خیر. اگر GC نباشد یعنی سرویس آن به هر دلیلی از کار افتاده باشد هیچکسی نمیتواند Login کند. دلیل آن امنیتی است. اگر GC  نباشد یک ریسک امنیتی میتواند به وجود بیاید و برای جلوگیری از این ریسک وقتی GC نیست کسی  نتواند لاگین کند.  ریسک امنیتی چیست؟ گفتیم وقتی یک User لاگین میکند باید برای آن Ticket صادر شود. Ticket را DC صادر میکند. در تیکت یک اطلاعاتی به این شکل  نوشته میشود که ” این User در این تاریخ در این ساعت Username و Password اش را ارسال کرده و همه چیز Ok هست و این User عضو این گروه ها است.” یعنی عضویت شما در گروه ها در تیکت نوشته میشود. چون شما میخواهید عضو یک resource  شوید و کسانی فقط میتوانند عضو آن resource باشند که عضو  گروه های مشخص شده باشند. پس باید تیکتش را نشان دهد و مشخص کند در چه گروه هایی عضویت دارد. این امکان وجود دارد که یک کاربر از یک دومین در یک گروه دیگر از یک دومین دیگر عضویت داشته باشد. زیرا مفاهیم اینکه دومین ها در یک فارست هستند و بین آنها Trust برقرار میشود یعنی همه از یک مجموعه هستند و یک سری مفاهیم مشترک دارند. حالا در زمان لاگین نمینویسد که یک کامپیوتر عضو چه گروه هایی از یک دومین دیگر در کل فارست است. در این شرایط  بهسراغ Global Catalog میرویم و Search میکنیم (Dc عمل Search را انجام میدهد) (این کار را سیستم انجام میدهد). حالا اگر نتوانیم Search کنیم میتوانیم دقیق بفهمیم یک کاربر عضو چه گروه هایی است؟ پس این یک مشکل امنیتی است. پس اگر نتواند search کند اصلا ticket هم صادر نمیکند.

   – اولین Domain Controller راه انداز Root Forest الزاما GC است و سرویس GC الزاما روی آن است. اما مابقی DC هایی که در کل فراست راه اندازی میشوند میتوانند نقش GC را داشته باشند یا نداشته باشند. این جمله یعنی اینکه شما میتوانید بیشتر از یک GC داشته باشید (redundancy). بنابراین ما در ساختار Forest باید حداقل دوتا GC راه اندازی کنیم. ماکزیمم آن هم باید در طراحی مان بهش فکر کنیم و اینطور نیست که همه ی DC ها را GC هم بکنیم. زیرا Overhead وارد میکند. GC ها باید Data هاشون رو با همدیگر Sync کنند. یعنی DC ها یکبار به واسطه ی DC بودنشان با همدیگر Replicate میکنند و یکبار هم انهایی که GC هستند با همدیگر Replicate میکنند. چون GC ها در کل فارست Global هستند همه باید باهم replicate کنند (فارغ از اینکه در چه Domain ای هستند). پس این هم خوب نیست که همه ی DC ها GC شوند.

   – اینکه چه کسی یا کسانی GC هستند در DNS ثبت میشود.

همانطور که قبلا گفتیم هر دومینی گروهی دارد به نام Domain Admin. Domain Admin یعنی ادمین کل آن دومین. هرکسی عضو این گروه باشد یعنی ادمین کلیه کامپیوترهای آن دومین است. Domain Admin یک دومین، هیچ کنترل مدیریتی روی دومین دیگر ندارد. حالا ما یک گروه دیگر داریم به نام Enterprise Administrator .گروه Enterprise Admin فقط روی Root Forest است. هرکسی عضو این گروه باشد ادمین تمامی Forest است. ادمین تمامی Forest به این معنی نیست که مثلا روی Root سیاستی رو ایجاد کند که به کل Forest اعمال شود. ادمین تمامی Forest فقط به معنی این است که دسترسی ادمینی دارد. یعنی مثلا میتواند در یک DC از یک Domain وارد شود و کنسول اکتیو دایرکتوری را باز کند و مثلا یک User بسازد. پس میتواند اعمال نفوذ داشته باشد به دومین های دیگر. حالا ما یک گروه دیگر داریم به نام Administrators. پس تا اینجا گروه هایی که در اکتیو دایرکتوری برای ادمین ها معرفی کردیم .

 – Domain Admin

 – Enterprise Admin

 – Administrators

گروه های دیگری هم برای ادمین ها وجود دارد که معرفی خواهند شد.

هرکسی عضو گروه Administrators باشد ادمین اون کامپیوتر خاص است ولی ادمین اکتیو دایرکتوری نیست.  ضمنا Domain Admin عضو گروه Administrators است. Enterprise Admin هم عضو این گروه Domain Admin است.

نویسنده:مهندس محمد آجورلو