Active Directory

Active Directory برای اولین بار در ویندوز 2000 ارائه شد. این بدین معنی نیست که ما قبل از آن مدیریت متمرکز نداشتیم. ما قبل از آن و در ویندوز NT نیز مدیریت متمرکز داشتیم اما این مدیریت با بر مبنای سرویس قدرتمند Active Directory نبوده است. در ویندوز 2000 مایکروسافت سرویس Active Directory را ارائه کرد و گفت از این به بعد شبکه های با این سرویس و به این شکل مدیریت متمرکز شوند.

یک کامپیوتر Server فقط میتواند نقش Active Directory را داشته باشد. یعنی سرویس Active Directory روی سیستم کلاینت نصب نخواهد شد. این ویندوز سرور هم حتما باید 2000 به بالا باشد.

همه ویندوز ها SAM دارند که Credential ها در آن ذخیره میشود. وقتی Active Directory روی کامپیوتر سرور نصب میشود SAM از بین میرود و به جای آن یک دیتابیس Active Directory ای میاد وسط. دیتابیس اکتیو دایرکتوری اسمش هست NTDS.DIT . یعنی وقتی شما Active Directory نصب میکنید لیست User ها و گروه ها و چیزهای دیگر در این دیتابیس ذخیره میشود و SAM از کار می افتد.

تفاوت خیلی زیادی  بین فایل NTDS.DIT و فایل SAM وجود دارد. همانطور که گفتیم قبل از ویندوز 2000 هم مدیریت متمرکز داشتیم. اما مدیریت متمرکزی بر پایه SAM. اما بعد از ویندوز 2000 مایکروسافت Active Directory را ارائه کرد که در آن NTDS.DIT وجود داشت. فرق SAM و NTDS.DIT مانند مثال زیر میماند:

تصور کنید ما یک انبار داریم و میخواهیم یک سری کالا در این انبار قرار دهیم. حالا مثلا شش ماه میگذرد و به ما میگویند کالای X را که چندماه پیش آوردیم را بیاور. حالا SAM مثل این میماند که ما از اول بیایم همینج.ری کالاها را بریزیم داخل انبار و جستجو در آن نیز بسیار مشکل خواهد بود. اما NTSD.DIT به این صورت است که ما به عنوان یک انباردار بیایم از روز اول کالاها را مرتب قفسه بندی کنیم و برای هر طبقه یک کد بگذاریم تا search کردن در آن بسیار سریع انجام میشود. پس SAM انباری است که هیچ طبقه بندی در آن نیست و NTDS.DIT انباری است که در آن طبقه بندی وجود دارد. به لحاظ Logically گفته میشود که NTDS.DIT هیچ محدودیتی برای حجم ندارد و شما هرچقدر که بخواهید میتوانید در آن داده ذخیره کنید. اما SAM فایلی بود که میگفتند حجم آن نباید از 40MB بیشتر شود. تقسیم بندی های Active Directory به صورت زیر است:

Domain:

بعد از اینکه شما اکتیو دایرکتوری را راه اندازی میکنید، کامپیوتر ها توسط اکتیو دایرکتوری مدیریت متمرکز میشوند. یعنی یک مجموعه کامپیوتر را میبریم زیر پرچم Active Directory تا روی آن ها مدیریت متمرکز اعمال شود. حالا این کامپیوتر ها میتوانند 20 تاشون توی تهران باشند 20 تاشون توی اصفهان باشند 40 تاشون یک طرف دیگری باشند. همه ی آن ها یک مدیریت متمرکزی بهشان اعمال میشود. به مجموعه ی این کامپیوترها یک Domain گفته میشود. بنابراین به مجموعه ای از کامپیوترها که تحت عنوان اسم یک دامین اکتیو دایرکتوری مدیریت متمرکز بهشان اعمال میشود Domain گفته میشود. راه اندازی اکتیو دایرکتوری هم به این صورت است که شما یک ویندوز سرور دارید و سرویس Active Directory روی آن فعال میشود. این کامپیوتر که داره به سرور Active Directory تبدیل میشود بهش میگویند Domain Controller که به اختصار به آن DC میگویند. اینکه اسم Domain ئه Active Directory چی باشد برای ما خیلی مهم است. چون ما میخواهیم کامپیوترها را بیاریم زیر یک Active Directory ای. کدام Active Directory؟ اینجاست که اسم آن مهم میشود. این اسم هم معمولا اسم سازمان ماست. مثلا اسم آن را Organization.com میگذاریم. اسم دومین تشکیل شده از اسم سازمانتان و یک Suffix یا پسوندی. نمادActive Directory به صورت زیر است:

حالا ممکن است در این دومین 5000 تا کامپیوتر وجود داشته باشد و موقعیت فیزیکی این کامپیوترها هم مهم نیست.

وقتی یک Domain به وجود می آید نیاز دارد که یک DC داشته باشد. Domain بدون DC اصلا معنی ندارد و انگار اصلا Active Directory روی آن نصب نشده است و اون DC شما حتما یک ویندوز سرور 2000 به بالا است. حالا وقتی یک DC درست کردیم و همه ی کامپیوترهای سازمان هم به زیر پرچم آن آمدند و تحت مدیریت متمرکز آن قرار گرفتند آیا همه ی زندگی مان اون یک کامپیوتر نخواهد شد؟ اگر ازبین برود چی میشود؟ همه چیز ازبین میرود. برای مثال هیچکسی دیگر نمیتواند Login کند. زیرا User ها هیچکدام روی Local خودشان نیستند و همه در فایل NTDS.DIT هستند که در DC است. خب حالا چی کار کنیم؟ ما میتوانیم برای یک دومین بیشتر از یک DC داشته باشیم. یک دومین میتواند هرچندتا که میخواهد DC داشته باشد. که مثلا اولی میشود DC1 و بعدی ها میشود Additional DC. تمامی این DC ها با  همدیگر Replicate میکنند. یعنی DC1 و DC2 و DC3 فرقی باهم ندارند و وقتی علی یک Account روی یکی درست میکند این اکانت روی بقیه هم هست.

یا روی یکی یک گروه درست میکنیم این گروه روی بقیه Replicate میشود و تمام اطلاعات DC ها شبیه همدیگر است. حالا یک کاربر میخواهد لاگین کند، اطلاعات احراز هویت خود را به کدام DC میفرستد؟ فرقی نمیکند به هرکدام که ارسال کند همه دیتابیس مشترک دارند و فرقی ندارند.

حالا چندتا DC داشته باشیم بهتر است؟ حداقل دوتا، حالا دیگه اینکه حداکثر چندتا باشد فرقی ندارد و بستگی به طراحی دارد. که اگر یکی از آنها Down شد جایگزین داشته باشد. نام این DC ها یکی نیست اما اینها DC های یک Domain هستند. کامپیوترها عضو DC نمیشوند که، عضو Domain میشوند. DC ها هم هیچ فرقی باهم ندارند و هیچ ارجحیتی به همدیگر ندارند.

حالا تصور کنید که یک نفر در یک Domain ای است که سه تا DC دارد و میخواهد لاگین کند. حالا میخواهد Username و Password اش را بفرستد. از کجا بفهمد که باید برای کی بفرستد یا از کجا بفهمد که چه کسی DC است؟ از طریق DNS.  از DNS میپرسد که DC های مثلا دومین IT.COM چه کسانی هستند؟ حالا DNS که قبلا اسم و IP ی DC ها توش Register شده میگه DC ها کدام ها هستند. بعد شما میرید به یکیشون وصل میشوید. به کدامشان؟ هیچ فرقی نمیکند. بنابراین اگر در یک شبکه DNS نباشد یا اخلالی در کار DNS Server اتفاق بیوفتد ارتباطات شبکه و اکتیو دایرکتوری تحت شعاع قرار میگیرد و امکان بسیاری از مشکلات وجود دارد. به همین دلیل وقتی دارید Active Directory رو نصب میکنید یکی از چیزهایی که اتوماتیک در Wizard نصب خودش نصب میشود DNS Server است. بسیاری از مشکلاتی که در شبکه هایی که Active Directory دارند DNS است.

(OU (Organizational Unitیا واحد سازمانی

ما در یک سازمان دپارتمان های مختلفی داریم. مثلا دپارتمان حراست، دپارتمان مالی، دپارتمان IT و … که هرکدام از این بخش ها کلی کارمند دارند که دارند در آن واحد کار میکنند. شما در Active Directory برای اینکه یک دسته بندی روی لیست User ها و چیزهایی که ذخیره میکنید میتوانید OU درست کنید و این OU ها مشابه همان چارت سازمانیتان باشد. این OU ها مثل فولدر میمانند. یعنی همه چیز از هم جدا میشود و در فولدر خودش قرار میگیرد. این OU هم اصولا بر اساس چارت سازمانی طراحی میشود و مجموعه آدم هایی که در یک OU قرار میگیرند حتما یک ربطی به همدیگر دارند.

OU سه قابلیت دارد:

   – نقش Container ای دارد. یعنی نقش یک فولدر را میتواند داشته باشد. تا بدین وسیله کسانی که در سازمانتان کار میکنند را بتوانید دسته بندی کنید و زمانی که کنسول Active Directory راباز میکنید همه چیز یک نظم و سازمانی دارد.

   – قابلیت Security Principal. یعنی شما میتوانید روی OU ها Group Policy اعمال کنید. یعنی مثلا همه ی کسانی که در یک OU هستند یک Group Policy رویشان اعمال شود و کسانی که در یک OU دیگر هستند یک Group Policy دیگر بهشان اعمال شود.

   – قابلیت Administrative Deligation. Deligation یعنی تفویض اختیار. یعنی مثلا کسانی رو تعیین کنیم و مسئولیت هایی را به آن ها بدهیم. یعنی میتوانیم یک سازمان را به OU های مختلف تقسیم کنیم و برای هر OU یک مسئول انتخاب کنیم و کارها را به او بسپاریم.

آشنایی با ساختار Tree در اکتیو دایرکتوری 

تصور کنید ما یک دومین IT.COM را داریم که این دومین چهارتا DC (DC1,DC2,DC3,DC4) دارد. OU بندی هم کردیم و کل User ها و Group ها را هم دسته بندی کردیم. حالا چه دلیلی دارد که از یک Domain دیگری استفاده کنیم؟

این مسئله را با ذکر مثال توضیح میدهیم. در نظام بانکی یک بانک مرکزی وجود دارد و چندین بانک که زیرشاخه ی آن هستند. بانک مرکزی برای ساختمان های خودش و آدم هایی که در بانک مرکزی استخدامند و کار میکنند یک دومین اکتیو دایرکتوری دارد. حالا آیا درست است که آدم هایی که در بانک ملی هستند در دومین بانک مرکزی باشند؟ باید برای افراد بانک ملی یک دومین دیگر راه اندازی کنیم. حالا سوالی که پیش می آید چرا افراد بانک ملی را در دومین بانک مرکزی عضو نکنیم؟ پاسخ یک چیز است، چون میخواهیم Isolation ایجاد بکنیم. یعنی بین مدیریت متمرکز سازمان های مختلف isolation ایجاد کنیم.

در Active Directoryهر دومینی یک گروه Admin مخصوص خود را دارد. هرکسی عضو گروه Domain Admin باشد ادمین تمامی کامپیوترهای آن دومین است. حالا اگر ما یک Policy را به یک OU اعمال کنیم اون Policy به چه کسانی اعمال میشود؟ به تمام کسانی که در اون ou اند. حالا ما میتوانیم یک Policy را به Root یک دومین اعمال کنیم. در این صورت Policy به هرکسی که داخل اون Domain است اعمال میشود. حالا اگر افراد بانک ملی در دومین بانک مرکزی دسته بندی بشوند مدیریت آن ها دست چه کسانی خواهد بود؟ دست بانک مرکزی. یعنی سیاست های غالب بانک مرکزی که در Root آن اعمال میشود به افراد بانک ملی هم اعمال میشود. همین افراد بانک ملی هم باید تحت یک OU عضو دومین بانک مرکزی باشند. در حالی که مثلا بانک ملت ساختمان های خودش را دارد، افراد و مدیران IT ی خودش را دارد و مدیریت شبکه اش کاملا نسبت به بقیه بانک ها Isolate است. بنابراین برای اینکه مدیریت را جدا کنیم میایم یک Domain دیگر راه اندازی میکنیم. بنابراین دلیل جداسازی دومین ها Isolation است.

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

• روش اول: Root Domain

• روش دوم: Child Domain

تفاوت این دو مدل چیست؟

اگر دومین Child شود باید اسم Parent اش را یدک بکشد. یعنی وقتی Child شدی اسم Parent ات را حتما باید بیاری. اما در روش اول اینگونه نیست. یعنی اینکه کسی Child کسی نیست که بخواهد اسم کسی را یدک بکشد. حالا سوال اینجاست که چرا باید به صورت Child درست بکنیم؟

تنها یک دلیل دارد و آن هم این است که دوست داریم هرکسی مثلا دومین Soft را میبیند بفهمد که برای گروه IT است. یعنی تنها دلیلش اسمی بودن آن است. یعنی باید توجه کنید که دومین IT هیچ چیز اضافه تری نسبت به دومین Soft ندارد و دومین Soft هم هیچ کمبودی نسبت به IT ندارد و تنها تفاوت آنها هم اسمی بودن آن است و دومین های مستقل و مجزا نسبت به هم هستند. یعنی همانطور که در شکل مشاهده میکنید هرکدام DC های مختلف خود را دارند و کاملا مجزا هستند.

هر دومین میتواند هرچندتا که میخواهد Child داشته باشد. برای مثال:

همانطور که میبینید شکل بالا شبیه یک Tree شده است.یعنی یک ساختار سلسله مراتبی از Parent ها و Child ها. توجه کنید که همه ی این ها Concept های Logically است. پس وقتی گفتیم Tree یعنی ما چندین Domain داریم که به لحاظ ساختاری زیر هم قرار گرفتند و مثلا شکل بالا را به وجود آورند.

حالا تا اینجا میتواند به این شکل باشد که ما یک دومین داشته باشیم برای بانک مرکزی و دومین بانک های دیگر Child های دومین بانک مرکزی شوند که جدا باشند ولی به لحاظ اسمی نام بانک مرکزی یا Parent شان هم یدک بکشند. برای مثال:

حالا آیا A چون از همه بالاتر است میتواند یک Policy به بقیه ی دومین ها اعمال کند یا مثلا Option اضافه تری نسبت به دومین های پایین تر دارد؟ خیر؛ زیرا کاملا مجزا است و هیچ policy ای را نمیتواند به Child های خودش اعمال کند. فقط یک ساختار اسمی است.

Forest

یکی از قابلیت های مهمی که Domain در اختیار ما قرار میدهد SSO (Single Sign on) است. وقتی شما با Credential ای که دارید در یک Domain لاگین میکنید، اگر Username و Password تان درست باشد از سمت DC های Domain برای شما یک Ticket صادر میشود. روی این Ticket نوشته که این user در این ساعت در این تاریخ توانست احراز هویت بشود و عضو این گروه هاست (یک مهر برجسته هم پایینش میزند). سپس به واسطه ی این Ticket میتوانند به جاهای مختلف در همان Domain وصل شوند بدون اینکه مجددا Username و Password ارسال کنم. حالا این SSO داخل یک Valid Domain است. یعنی User هایی که در یک Domain هستند Ticket شان در یک Domain ی دیگر قابل قبول نیستند.

حالا تصور کنید که یک فایل سرور در یک Domain است و کامپیوتر ها در Domain دیگر میخواهند به این فایل سرور وصل شوند. طبیعتا نمیشود که هربار بخواهند Username و Password بزنند زیرا SSO فقط داخل یک Domain به کار می آید. در اینجا با مفهومی آشنا میشویم به نام Trust. در این شرایط می آییم بین Domain ها Trust برقرار میکنیم. وقتی Trust بین Domain ها برقرار میشود حالا Ticket ها هم در آن Domain مورد قبول قرار میگیرد (مثل کشورها که Trust کردند به همدیگر و برای رفت و آمد ویزا نمیخواهند).

Trust از دو جهت مورد بررسی قرار میگیرد. یک انواع عملکردی دارد و یک انواع حالت های کاری که مورد دوم در جلسات آینده بحث خواهد شد. Trust از نظر انواع حالت های عملکردی به صورت زیر تقسیم بندی میشود:

حالا میخواهیم ببینیم تفاوتشان در چیست. ما دو Domain ، A و B زیر را داریم و میخواهیم بین آنها Trust ئه One Way برقرار کنیم. طبق شکل A به B ، Trust دارد(به خط trust توجه کنید). این به این معنی است که Account ها و User های دومین B ، Ticket شان در A مورد قبول است اما User های A، Ticket شان در B مورد قبول نیست. به بیان دیگر اگر در A یک File Server وجود داشته باشد و یک نفر از B بخواهد برود به A و از آن استفاده کند، Ticket اش را که به فایل سرور A نشان دهد، فایل سرور A به واسطه ی Trust ای که به B دارد میگه اوکی بیا!

ما اگر یک نفر از دومین A بخواهد از فایل سروری که در B است استفاده کند ticket اش مورد قبول نیست. فقط توجه داشته باشید که خط Trust با خط حرکت User ها متفاوت است. همانطور که مشخص است این Trust عملکردی یک طرفه دارد. حالا trsut میتواند دو طرفه باشد. یعنی به این واسطه دو طرف به همدیگر اعتماد داشته باشند. اگر ما Trust دو طرفه نداشته باشیم مجبوریم یکبار A به B ، Trust داشته باشد و یکبار هم B به A، Trust داشته باشد. اما اگر دوطرفه باشد به واسطه یک Trust دو طرف به همدیگر اعتماد خواهند کرد.

حال به شکل زیر نگاه کنید. همه ی Domain ها میخواهند به همدیگر trust کنند. فرض کنید Trust دو طرفه نداریم. چند Trust نیاز داریم؟ 6 تا یکطرفه. چند Trust دو طرفه احتیاج داریم؟ 3 تا. پس خوبی Trust دو طرفه این است که به واسطه ی برقراری یک Trust دوطرف به همدیگر اعتماد میکنند

نوع سوم Two Way Transitive است. همانطور که میدانید رابطه ی تعدی به صورت زیر است:

حالا شکل بالا به صورت زیر میشود:

• Forest:

به مجموعه ای از Domain ها که بینشان Trust دوطرفه ی Transitive برقرار است و این trust هم قابل پاک شدن نیست و اتوماتیک به وجود آمده است Forest گفته میشود.

زمانی که شما میخواهید trust دوم را درست بکنید این دومین میخواهید در Forest دومین اولی باشد؟ شما اگر بگویید آره بینشان اتوماتیک Trust دو طرفه برقرار میکند و شما بعدا نیز این Trust دو طرفه را نمیتوانید پاک کنید.

 -وقتی برای اولین بار یک دومین را ایجاد میکنید در حقیقت یک Forest راه اندازی کردید. منتها Forest ای که یک دومین دارد. حالا دومین دوم را که میخواهید راه اندازی کنید از شما میپرسد که این دومین قرار است به عنوان یک Forest جداگانه طراحی شود یا قرار است بره در دل  یک Forest موجود؟ مثلا ما میگوییم بره در یک Forest موجود. بعد از شما میپرسد نام این Forest موجود چیست؟ جالب توجه است که نام اولین دومین راه انداز میشود نام Forest. برای مثال در شکل مربوط به Child ها اسم Forest میشود COM .

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