در مقاله قبلی که با عنوان معرفی نقش های موجود در ویندوز سرور 2008 بود توضیحاتی در خصوص نقش های مختلفی که در ویندوز سرور 2008 اضافه شده اند ارائه کردیم ، در این مقاله به بررسی یکی از همین سرویس ها که به نام Active Directory Lightweight Directory Service یا به اختصار ADLDS معروف است ، می پردازیم . همانطور که در مقاله قبلی تا حدودی به این سرویس و معرفی هویت آن پرداختیم ، سرویس ADLDS یک نسخه کم حجم از ساختار اکتیودایرکتوری است .
هنوز مفاهیم مربوط به LDS برای بسیاری از کارشناسان فناوری اطلاعات تازگی دارد اما بایستی بدانید که این سرویس از سیستم عامل ویندوز سرور 2003 نسخه R2 به دنیای فناوری اطلاعات توسط شرکت مایکروسافت معرفی شد. نکته جالب در خصوص این سرویس این است که ضمن اینکه این سرویس خود به تنهایی یک دایرکتوری سرویس است اما کاملا مستقل و بدون وابستگی به ساختار اکتیو دایرکتوری کار می کند و به نوعی مستقل است . با معرفی ویندوز سرور 2008 و همچنین قرار گرفتن این سرویس به عنوان یکی از نقش های موجود بر روی سرور 2008 ، کاربرد این نقش نیز تا حدودی گسترش پیدا کرد . در ویندوز سرور 2003 این سرویس به نام ADAM یا Active Directory Application Mode معروف بود.
همانطور که اشاره کردیم ADLDS نسخه بروز شده و جدیدتری از نمونه قبلی خود است که در ویندوز سرور 2003 نسخه R2 با نام ADAM معرفی شد ، طبیعی است که با ارتقاء یافتن و بروز رسانی این سرویس امکانات و ویژگیهایی نیز به آن اضافه شده است که در ادامه برخص از مهمترین تغییران به وجود آمده در این سرویس نسبت به نسخه قبلی آن را مشاهده می کنید :
با توجه به موارد بالا حتما متوجه شده اید که تغییرات بسیار عمده و کلیدی ای در ADLDS نسبت به ADAM که در ویندوز سرور 2003 انجام شده است اما فراموش نکنید که این محصول هنوز بصورت یک محصول عملیاتی در محیط های کاربردی چندان مورد استفاده قرار نمی گیرد و به قول ITMAN ها هنوز برای ورود به ساختار کاری پخته نشده است ، اما قطعا در صورت ورود به ساختار کاری بسیار بسیار می تواند کار مدیریت دایرکتوری سرویس ها را آسان کند .
با وجود اینکه ساختار ADLDS به ساختار ADDS شباهت دارد اما کار با آن ساده تر از ADDS می باشد بعنوان مثال با نصب ADLDS تغییراتی در ساختار سرور شبیه به آنچه در ADDS اتفاق می افتد ایجاد نخواهد شد .سرویسهای ADLDS صرفا یک برنامه یا application بوده و بعد از نصب نیاز به راه اندازی دوباره ی سرور نیست چون ساختار سرور تغییر نکرده است. به بیانی دیگر ADDS سرویسهای دایرکتوری را برای ویندوز سرور و برنامه های کاربردی فعال شده در دایرکتوری فراهم می آورد و اطلاعات مهم مربوط به زیرساختهای شبکه،کاربران وگروهها و سرویسهای شبکه را برای سیستم عامل سرور ذخیره می کند.
ADDS باید به یک شمای واحد در سراسر یک Forest پایبند باشد در مقابل ADLDS سرویسهای دایرکتوری را تنها برای برنامه های کاربردی موجود در دایرکتوری ایجاد می کند و نیازی به دامین ADDSو Forest ندارد با این حال ADLDS در محیطی که ADDS وجود دارد از آن برای احراز هویت ویندوز استفاده می کند. ADDS و ADLDS می توانند بطور همزمان در یک شبکه اجرا شوند علاوه بر این ADLDS می تواند از کاربران دامین و کاربران work group بطور همزمان پشتیبانی کند.
ADLDS نیز همانند ADDS براساس پروتکل LDAP عمل می کند و ساختاری منطقی و سلسله مراتبی بوجود می آورد. هر دوی این ساختارها به نوعی پایگاه داده هستند اما ساختار ADLDS با ساختارهای Relational Databaseهمچون Microsoft SQL server بسیار متفاوت است این تفاوتها در جدول زیر عنوان شده است با مقایسه آنها می توان دریافت که در چه مواقع می توان بجای ساختارهای Relational Database از این نوع سرویسهای دایرکتوری استفاده کرد. در خصوص انواع پایگاه های داده می توانید به لینک زیر برای بدست آوردن اطلاعات بیشتر مراجعه کنید:
باوجود اینکه ADDS و ADLDS ساختار مشابهی دارند اما میان برخی ویژگیهای آنها تفاوت هایی وجود دارد .در جدول زیر برخی از این تفاوت ها بیان شده:
خوب ممکن است این سئوال برای شما پیش بیابد که چرا ما از LDS استفاده کنیم در حالی که می توانیم از سرویس اکتیودایرکتوری استفاده کنیم ؟ در پاسخ به این سئوال بایستی اشاره کنیم که در برخی موارد ما نیاز به یک ساختار دایرکتوری سرویس مرکزی برای احراز هویت و همچنین ایجاد کاربران شبکه داریم ، اما در عین حال نیازی به استفاده از ساختار های پیچیده Domain و Forest و بسیاری دیگر از این موارد که بار کاری سختی را بر عهده سرور میگذارد نداریم ، در این حالت به جای استفاده از اکتیودایرکتوری از ساختار LDS استفاده می کنیم .
بر خلاف Active Directory Domain Services که ساختار دامین بر اساس Tree و Forest و Domain می باشد ، ساختار LDS ساختاری ساده و بدون وجود دردسرهای اکتیودایرکتوری دارد . اما هنوز هم در این بین ابهامی وجود دارد که در کجا ما از ADDS و در کجا از ADLDS استفاده می کنیم ، برای اینکه این موضوع برای شما بیشتر جا بیافتد با یک مثال جلو می رویم ، در طراحی ساختارهای شبکه یک طراحی به نام DMZ یا Demilitarized Zone وجود دارد که بدین معنی است که در صورتیکه شرکتی یا سازمانی بخواهد به بیرون از سازمان سرویس دهی کند
این سرویس های و شبکه داخلی سازمان نبایستی بصورت مستقیم از بیرون سازمان قابل مشاهده باشند ، برای این طراحی در بین شبکه داخلی و شبکه اینترنت یک شبکه یا بهتر بگوییم یک محیط ایزوله با تعدادی سرور و سرویس قرار می گیرد که ضمن اینکه با شبکه داخلی ارتباط دارد به بیرون نیز سرویس دهی می کند ، تمامی این سرویس هایی که در این محیط قرار دارند نیاز به یک سیستم احراز هویت مرکزی دارند ، در اینجا شما اگر از ADDS داخلی شبکه استفاده کنید امنیت را بسیار بسیار پایین آورده اید .
به جای استفاده از این ساختار ، شما در همان محیط DMZ می توانید یک LDS نصب و راه اندازی کرده و تمامی سرویس های خود را به وسیله آن احراز هویت کنید و در عین حال شما می توانید با استفاده از پروتکل LDAP با دامین کنترلر شبکه داخلی نیز مرتبط باشید و جالب اینجاست که ایندو کاملا مستقل از هم عملی میکنند . در زیر تصویری مفهومی از ساختار DMZ و استفاده ADLDS در آن را مشاهده می کنید . برای دریافت اطلاعات بیشتر در خصوص ساختارهای DMZ می توانید به لینک زیر مراجعه کنید :
معمولا ADLDS زمانی استفاده می شود که برنامه های کاربردی اکتیو دایرکتوری به خدمات و سرویسهای دایرکتوری نیاز دارند اما نیازی به ارث بری از یک ساختار Forest یا دامین نیست. اکثر کامپیوترهای موجود در شبکه های محلی تحت پوشش یک فایروال قرار دارند که می توانند به یک شبکه عمومی مثل اینترنت متصل شوند .DMZ یا Demilitarized Zone یک محیط حفاظت شده ایجاد می کند که که بواسطه آن کاربران می توانند به یک شبکه عمومی دسترسی داشته اما کاربران خارجی (خارج از محدوده ی فایروال) نتوانند هیچگونه دسترسی به سیستم داخلی که تحت پوشش فایروال قرار دارد داشته باشند .
در واقع DMZ یک لایه اضافی برای حفاظت از کامپیوترهای موجود در یک سازمان (محدود به فایروال)در مقابل کاربران خارجی فراهم می کند.با استفاده از LDS می توان tفعالیت های غیر ضروری را حذف کرده و روی آن چیزی که واقعا مهم است همچون احراز هویت و کنترل دسترسی ها تمرکز کرد یکی از کاربردهای رایج LDS هنگامیست که می خواهیم یک سری سرویسهای احراز هویت را برای DMZ یا در اکسترانت مثلا برای کاربران بزرگ شرکتهای بزرگ داخلی فراهم کنیم .در اینجا می توان گفت که حسابهای اعتباری میان یک دامین کنترلر و یک نمونه از LDS در داخل DMZ باید تطابق داشته باشد .این قضیه یک راه یک جهته برای ورود به سیستم فراهم می کند و این با داشتن کاربرها و پسوردهای متفاوت برای کاربران نهایی در تناقض است.
در صورتیکه بخواهیم کاربرانی را که به برنامه های تحت وب و یا سرورهای وب دسترسی دارند احراز هویت کنیم نیز می توانیم از ADLDS استفاده کنیم بدین صورت که یک شبکه DMZ ایجاد و سرویسهای وب مورد نظر را درون آن قرار می دهیم سپس روی آن شبکه محیطی سرویس ADLDS را نصب می کنیم .این سرویس برای احراز هویت کاربران (بصورت ایمن ) با سرویسهای ADDS موجود در شبکه داخلی ارتباط برقرار کرده و اطلاعات را در خود ذخیره می کند این امر موجب می شود که از گسترش سرویس ADDS و سرورهای DC درون شبکه DMZ بی نیاز شویم و این باعث افزایش امنیت اگر پایگاه داده بصورت publish باشد بدلیل پشتیبانی ADLDS از multi master replication باز هم می توان از آن بجای ADDS بهره گرفت.اگر بخواهیم یک نرم افزار برای شبکه های مبتنی بر سرویسهای دایرکتوری ایجاد کنیم انجام این عمل با ADLDS بسیار آسانتر از ADDS خواهد بود .
با وجود اینکه دامین کنترلر و سرور ADLDS ساختار بسیار مشابهی دارند واقعیت اینست که DC برای تشخیص هویت کاربران و اجرای policy های امنیتی کاربرد دارد .این بدان معنیست که برخی از جنبه های برنامه ریزی دامین کنترلر به سادگی برای فرایند برنامه ریزی ADLDS اعمال نمی شود.یکی از تفاوتهای ADLDS با DC در این است که ADLDS از مفهوم Forest همچون ویندوز اکتیو دایرکتوری استفاده نمی کند .
در محیط اکتیو دایرکتوریForest به مجموعه ای از دامینها اطلاق می شود و هر Forest کاملا مستقل می باشد با این وجود هر چند تا Forest می توانند با استفاده از مفهوم trust به همدیگر الحاق شوند . ADLDS از مفهوم Forest و دامین مانند DC استفاده نمی کند در عوض عنصر اصلی ساختاری که توسط ADLDS مورد استفاده قرار می گیرد یک نمونه سرویس است (مایکروسافت اغلب بعنوان یک نمونه یا instance به آن اشاره می کند ) این نمونه به یک تک پارتیشن ADLDS رجوع می کند و هر کدام از این نمونه ها دارای service name منحصر به فرد مربوط به خود و دایرکتوری ذخیره اطلاعات و service description می باشند.
ویندوز دامین کنترلر تنها می تواند به یک دامین واحد سرویس دهی کند در حالیکه یک تک سرور در حال اجرای ADLDS می تواند میزبان instance یانمونه های متعددی باشد. در محیط اکتیو دایرکتوری کاربران با یک پروتکل بنام LDAP یا Lightweight Directory Access Protocol ارتباط برقرار می کنند LDAP دارای پورت مخصوص به خود است بعنوان مثال LDAP معمولا از پورت 389 برای query گرفتن از دایرکتوری استفاده می کند اگر ارتباطات دایرکتوری بصورت رمز گذاری شده (encryption) باشد از پورت 636 استفاده خواهد کرد . دامین کنترلر بعنوان یک global catalog server از پورتهای 3268 و3269 برای توابع مربوط به global catalog استفاده می کند.ADLDS هیچگونه مشکلی برای اجرای توابع global catalog ندارد بنابراین می توانیم از استفاده پورتهای 3268و3269 جلوگیری کنیم ADLDS از پورتهای 389 و 363 دقیقا به همان شیوه ی یک دامین کنترلر استفاده می کند.
حال این سوال پیش می آید که اگر سرور میزبان چند نمونه از ADLDS داشته باشد چه اتفاقی خواهد افتاد؟ به طور معمول به نمونه اولیه ساخته شده پورتهای 389 و 636 اعمال می شود .وقتیکه نمونه ثانویه ساخته شد ،ویندوز پورتهای استفاده شده را تشخیص داده و شروع به اسکن پورتهای استفاده شده با پورت 50000 می کند اگر این پورت در دسترس باشد از آن برای ارتباط استاندارد LDAP با نمونه (instance) ثانویهADLDS استفاده خواهد کرد.
و نیز پورت 50001 برای رمزگذاری ارتباطات LDAP با instance ثانویه ADLDS توسط SSL استفاده خواهد شد.اگر سومین نمونه ADLDS را نیز ایجاد کنیم پارتیشنهای سوم LDAP به پورتهای 50002و 50003 تخصیص می یابند.تفاوت دیگر میان DC و ADLDS در این است که اکتیو دایرکتوری دامین کنترلر وابسته به DNS بوده و بدون وجود آن اکتیو دایرکتوری عملا هیچ گونه کاربردی ندارد در مقابل ADLDS به DNS نیاز ندارد. مثلا اکتیو دایرکتوری از DNS بعنوان یک مکانیزم برای حفظ سلسله مراتب دامین ها استفاده می کند .اما در ADLDS سلسله مراتب دامین وجود ندارد بنابراین استفاده از DNS غیر ضروری بنظر میرسد.در مقاله بعد مراحل نصب ADLDS رابصورت تصویری و قدم به قدم با هم دنبال خواهیم کرد.
کارشناس شبکه های مایکروسافت و پایگاه داده
کارشناس سیستم عامل و زیرساخت های مایکروسافت MCTS:Active Directory 2008 MCTS:Network Infrastruture 2008 MCTS:Application Infrastructure 2008 MCTS:Active Directory 2008 MCITP:Enterprise Administrator MCSA 2008
زمان پاسخ گویی روز های شنبه الی چهارشنبه ساعت 9 الی 18
فقط به موضوعات مربوط به محصولات آموزشی و فروش پاسخ داده می شود