آشنایی با اکتیو دایرکتوری 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
حالا تصور کنید ما در گام صفر می‌خواهیم یک دومین جدید راه اندازی کنیم و هیچ دومین دیگری نداریم و در اینجا باید یک Forest جدید درست بکنیم. اولین دومین راه انداز فارست جدید را Root Forest می‌گویند. همچنین اسم دومین Root Forest اسم کل فارست میشود. حالا این فارست میتواند یک سری Child داشته باشد و همچنین میتواند Root Tree داشته باشد. اگر به یاد داشته باشید گفته بودیم که چه شرایطی باید پیش بیاید که بخواهیم یک دومین جداگانه داشته باشیم که در پاسخ گفتیم بحث، بحث Isolation است. یعنی شما میخواهید یک سری از Userها در یک دومین جداگانه با یک مدیریت کاملا مجزا باشند و یک سری کامپیوتر هم در یک دومین دیگر باشند با یک مدیریت مجزای دیگر و نمیخواهیم آن ها را در یک دومین دسته‌بندی کنیم چرا که اگر در یک دومین دسته بندی شوند یک مدیریت به آنها اعمال میشود. گفتیم دومین میتواند Chid یا Parent باشد که اگر Parent باشد به آن می‌گویند Root Tree.
اکتیو دایرکتوری NTDS.DIT
همانطور که قبلا گفتیم اسم دیتابیس اکتیو دایرکتوری NTDS.DIT است. ما در داخل این دیتابیس یک سری پارتیشن داریم (اینکه می‌گوییم طبقه بندی شده‌اند منظور همین پارتیشن‌ها است). در هریک از این پارتیشن‌ها هم میتوانیم یک سری اطلاعات ذخیره کنیم. NTDS.DIT پارتیشنی به نام Schema. Schema و به معنای الگو یا مدل دارد. در اکتیو دایرکتوری شما میخواهید Object درست کنید، مثلا Object که User. این ابجکت User باید یک الگوی ساخت داشته باشد. در Schema الگوی ساخت Object ها قرار گرفته است. یعنی اگر قرار شد مثلا Userr 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
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 است.
