Offline Domain Join

Offline Domain Join ابزاری است که برای Windows Server 2008 R2 و Windows 7 یا نسخ جدید تر ویندوز در دسترس است. با استفاده از این فرآیند برای Join شدن به Domain نیازی به برقراری ارتیاط با Domain Controller وجود ندارد. این ویژگی برای سایت هایی که دارای ارتباط شبکه با شبکه سازمانی نیستند در نظر گرفته شده است (همانند سایت های موقت)

به عنوان مثال ممکن است تعدادی ماشین مجازی (Virtual Machines) در یک Data Center ایجاد کرده باشید. با استفاده از Offline Domain Join این امکان پدید می آید که بدون هیچ Restart اضافی در اولین استارت آن ها عضو دامین شوند. مهمترین مزیت Offline Domain Join آن است که وضعیت عضویت در شبکه Active Directory بدون هیچ ترافیک شبکه ای تغییر می کند. چهار قدم اصلی برای انجام Offline Domain Join لازم است:

ادامه نوشته

نصب AD DS در Server Core Installation

مقدمه

در بسیاری از سناریو ها لازم است امنیت دامین کنترلر ها به بالاتر این شکل ممکن تامین گردد و ریسک نفوذ مینیم شود در این شرایط ممکن است استفاده از نسخه Server Core Installation ویندوز سرور ۲۰۰۸ می تواند مفید واقع شود. Core Installation نصبی از ویندوز با اولیه ترین امکانات است که حتی شامل Windows Explorer GUI هم نیست. بنابراین لازم است مدیر شبکه های بر پایه ویندوز سرور ۲۰۰۸ آشنایی مناسبی با خط فرمان داشته باشد. در این بخش به نحوه نصب AD DS روی Core Installation پرداخته می شود. از این پس Windows Server Core Installation را به اختصار Server Core می گوییم. در Server Core همانطور که گفته شد تمام Role ها و Feature ها در دسترس نیست اما می تواند امنیت را بهبود ببخشد. هر چند در Server Core دسترسی به GUI وجود ندارد و باید از Command line جهت مدیریت استفاده کرد اما امکان مدیریت به صورت Remote موجود است و می توان با استفاده از MMC به مدیریت Romote سرور پرداخت. همانطور که گفته شد در Server Core از تمام Role ها پشتیبانی به عمل نمی آید و فقط از ۹ Role مهم زیر پشتیبانی می شود: ( در تاریخ نگارش این مطلب)

ادامه نوشته

Universal Group Membership Caching

در مدیریت گروه ها اشاره شد که نوعی از گروه ها (Group Scope) به نام Universal وجود دارد که می توانند شامل اشیاء (کاربران و گروه های دیگری) از چند دامین در یک Forest (جنگل) باشند. تمام Membership های unversal group از طریق Global Catalog (کاتالوگ جهانی) Replicate خواهد شد. زمانی که یک کاربر logon می کند، عضویت کاربر در Unversal Group ها توسط GC معین می گردد. اگر GC  در دسترس نباشد آنگاه Membership ها در Universal Group در دسترس نخواهد بود. از سوی دیگر، ممکن است از یک unversal group برای deny کردن دسترسی (جلوگیری از دسترسی) به منبعی استفاده شده باشد. ویندوز به دلیل عدم بروز مشکل امنیتی به این دلیل از Authentication کاربر سرباز می زند. اگر کاربر قبل از down شدن GC به سیستم وارد شده باشد، با استفاده از cache شدن Credential می تواند به سیستم وارد شود. اما در زمانی که می خواهد به یک منبع از طریق شبکه دسترسی پیدا کند، دسترسی Deny خواهد شد. به صورت خلاصه؛ اگر Global Catalog در دسترس نباشد، به طرز موثری کاربران از دسترسی به منابع روی شبکه باز خواهند ماند.

اگر تمام DC ها GC نیز باشند، این مسئله بر طرف می گردد. از این رو همواره تذکر داده می شود که به صورت ایده آل تمام DC ها GC هستند. اما از سوی دیگر Replication یک نگرانی است و این مسئله سبب می شود که تا از شرایط ایده آل فاصله بگیریم. از این رو، با استفاده از راهکار Universal Group Membership Caching یا UGMC روشی فرآهم می آید تا در صورت در دسترس نبود GC مشکلات به حداقل برسد. به عنوان مثال، زمانی که UGMC روی یک DC در شعبه سازمان تنظیم شده باشد، زمانی که کاربر logon می کند، DC اطلاعات Unversal Group Membership را از GC به دست می آورد و آن اطلاعات را برای مدت نامحدودی Cache می کند. هر هشت ساعت یک بار، DC تلاش می کند تا با استفاده از GC آن اطلاعات را به روز کند. بنابراین اگر کاربر در زمانی که GC در دسترس نیست logon کند، DC می تواند از اطلاعات Cache شده ی خود برای تعیین دسترسی کاربر استفاده کند.

از این رو، شدیدا توصیه می گردد در سایت هایی که دارای یک Link قابل اعتماد (Reliable) به یک GC نیستند قابلیت UGMC را در DC های آن ها فعال کنید. برای تنظیم UGMC:

1) به کنسول Active Directory Sites and Services رفته و سایت مورد نظر را انتخاب کنید.

۲) روی NTDS Site Settings کلیک راست کرده و properties را بزنید.

۳) در زبانه Site Settings می توانید قابلیت Universal Group Membership Caching فعال/غیرفعال کنید.

دامین کنترلرهای فقط خواندنی یا RODC

Read-Only Domain Controller ها یا RODC ها  Additional Domain Controller هایی هستند که یک نسخه فقط خواندنی از پارتیشن ها نگه داری می کنند. RODC ها برای قرارگیری در شعبه های شرکت اصلی یا Branch Office ها ساخته شده اند. معمولا این Branch Office ها شرایط محدود کننده ای همانند پهنای باند کم، امنیت فیزیکی نا مناسب، عدم وجود تکنسین شبکه، تعداد کم کاربر و دانش ناکافی در زمینه IT دارند بنابراین نگه داشتن یک دامین کنترلر در آنها ریسکی بزرگ است و امنیت تمام شبکه را به مخاطره می اندازد. این Branch Office ها معمولا با استفاده از یک WAN یا MAN به Main Office یا دفتر مرکزی متصل می شوند همچنین معمولا Branch Office ها با هم متصل نیستند به عبارت دیگر فقط یک لینک کم سرعت بین دفتر شعب و دفتر مرکزی موجود است و لینک پشتیبان وجود ندارد. همچنین پهنای باند لینک موجود هم بسیار کم است و ارتباط از کیفیت مناسبی نیز برخوردار نیست.

ادامه نوشته

مدیریت دامین های چندتایی

ممکن است محیط Enterprise دارای چند دامین باشد، در این صورت فرآیند های مدیریتی پیچیده تر از حالت تک دامینی (Single Domain) است. ممکن است لازم باشد تا اشیائی میان دامین ها انتقال پیدا کند و یا ساختار دامین ها باز سازی شوند. شاید لازم باشد که تشخیص هویت و دسترسی به منابع در بین دامین ها یا درخت ها انجام شود. با توجه به دورنمایی که در مدیریت سایت ها در اکتیو دایرکتوری به دست می آورید و مدیریت دامین های چند تایی می توانید ساختار کامل اکتیو دایرکتوری را مدیریت کنید و آماده به طراحی محیط اکتیو دایرکتوری شبکه های Enterprise شوید.

ادامه نوشته

روابط Trust – قسمت دوم

Trust های دستی

۴ نوع Trust هستند که باید به صورت دستی ساخته شوند:

آ: Shortcut Trust
ب: External Trust
پ: Realm Trust
ت: Forest Trust

ساخت یک Trust به صورت دستی

با توجه به Trust که قصد ساختن آن را دارید و نحوه ی آن باید عضو گروه Domain Admins یا Enterprise Admins باشید. برای ساخت یک Trust به صورت دستی قدم های زیر را طی کنید:

ادامه نوشته

روابط Trust – قسمت اول

موضوع مدیریت دامین های چند تایی به مدیریت روابط Trust بسیار گره خورده، به عبارت دیگر دامین های چند تایی در سایه روابط Trust امکان پذیر می شوند.

ارتباطات Trust در یک دامین

در زمان عضویت کامپیوتر در دامین، زمانی که کامپیوتر هنوز عضو شبکه Workgroup است، کامپیوتر اطلاعات مربوط به کاربران را در پایگاه داده SAM یا Security Account Manager نگه داری می کند. در زمان تشخیص هویت تنها با استفاده از پایگاه داده SAM اطلاعات را کنترل می کند. زمانی که کامپیوتر عضو دامین می شود یک رابطهTrust داخل دامینی بین کامپیوتر و دامین برقرار می شود. نتیجه این رابطه آن است که کامپیوتر اجازه می دهد تا هویت کاربر توسط AD DS تایید شود. همچنین با استفاده از این رابطه، AD DS قادر می شود تا روی دسترسی به منابع نیز مدیریت داشته باشد.

ادامه نوشته

مدیریت گروه ها

به دلیل تعدد تعداد User ها مدیریت آن ها عملا غیر ممکن است. به همین دلیل از گروه هایی استفاده می کنیم تا مدیریت ها در محیط اکتیو دایرکتوری ساده تر صورت گیرد. از طرف دیگر، با گذر زمان، کاربران، کامپیوتر ها و سرویس ها در محیط اکتیو دایرکتوری تغییر می کنند و در صورت مدیریت مستقیم روی کاربران، سبب دوباره کاری می شود. به عنوان مثال ممکن است در سازمان، حتی تنها یک کاربر خاص به دسترسی هایی که سایر کاربران ندارند لازم داشته باشد. در این شرایط هم حتی باید از یک Group که تنها همان یک کاربر عضو آن است استفاده شود.

ادامه نوشته

Delegation

اکتیو دایرکتوری معمولا به عنوان یک سامانه مرکزی امنیتی و تعیین هویت توسط سازمان ها شناخته می شود که سبب کاهش هزینه های نگه داری و مدیریت ساده تر روی کاربران می شود. اما همواره برخی سازمان ها، به ویژه سازمان های کوچک و سازمان های با بروکراسی، با سوالاتی نظیر، اگر مدیریت غیر مرکزی در بخش ها مختلف لازم باشد، آیا مدیران هر بخش دسترسی به اندازه کافی محدودی دارند، مدیریت روی یک شیئ موجود در data store اکتیو دایرکتوری فقط توسط مدیر موجه می تواند صورت گیرد و سوالاتی از این قبیل دارند. برخی از مدیران شبکه برای این دسته از موضوعات به راهکار دامین های چند تایی روی می آورد.

ادامه نوشته

مدیریت پرینترها

دسته دیگری از اشیاء که در اکتیو دایرکتوری قرار می گیرند، Printer ها هستند. برای در دسترس بودن یک پرینتر در محیط اکتیودایرکتوری باید آن را منتشر کرد. اولین دلیل انتشار پرینتر، پیدا کردن راحت تر کاربران است. به صورت پیش فرض در ویندوز سرور ۲۰۰۰ و ۲۰۰۳ زمانی که یک پرینتر Share می شود در محیط اکتیو دایرکتوری منتشر می شود. اگر می خواهید این فرآیند در ویندوز سرور ۲۰۰۸ نیز خودکار صورت گیرد، در Properties مربوط به پرینتر مورد نظر، در Tab (زبانه)Sharing گزینه مربوطه را Checked کنید. زمانی که یک پرینتر در محیط اکتیودایرکتوری منتشر می شود، به صورت خودکار در زیر شیئ کامپیوتر در DataStore ذخیره می شود. برای مشاهده این اشیاء در کنسول Active Directory Users And Computers از منوی View گزینه Users,Groups and Computers as Container را enable کنید.

ادامه نوشته

AD AC

در این مطلب قصد داریم نگاهی بر ابزار جدی Active Directory Administration Center داشته باشیم. این ابزار جدید با Windows Server 2008 R2 وارد شده و جایگزین مناسبی برای کنسول قدیمی Active Directory Users and Computers به شمار می آید. در این پست بیشتر تلاش شده تا از تصاویر جهت تشریح استفاده شود همچنین از توضیح مفاهیم در این پست صرف نظر شده است و صرفا در خصوص ابزار توضیح داده شده است. انتظار یک معجزه را از این ابزار نداشته باشید. فقط کمی دسترسی ها ساده تر و سریع تر شده است. اما ویژگی اصلی آن زمانی به چشم می آید که قصد داشته باشید چندین دامین مختلف را که با لینک های نه چندان پر سرعت به هم متصل هستند از راه دور مدیریت کنید. جهت نصب ابزار به موارد زیر توجه داشته باشید.

ادامه نوشته

Replication – 3

پس از آنکه Connection Objects بین دو Domain Controller در یک سایت برقرار شد (چه به صورت دستی و چه به صورت خودکار توسط KCC) عملیات Replication اتفاق می افتد. Replication بین چند سایت شامل تغییرات در یک سایت خواهد بود. عملیات Replication به صورت دو به دو بین دو DC اتفاق می افتد. Replication Topology تعیین کننده ی آن است که چه DC هایی با یکدیگر به عنوان Partner فعالیت داشته باشند. زمانی که KCC یک Topology ایجاد می کند در واقع، تعدادی  Connection Object را روی Destination DC ایجاد می کند که معرف ارتباط ورودی از سمت Source DC خواهد بود.

ادامه نوشته

Replication – 2

Intersite & Intrasite Replication

در اینجا به بررسی نحوه انجام Replication  به صورت Interasite (در یک سایت) و Intersite (بین چند سایت) می پردازیم. در هر دو حالت DC ها برای بهینه سازی ترافیک Replication از یک روش استفاده می کنند. هر چند که یکی از دلایل اصلی برای ساخت سایت ها و مدیریت لینک ها، مدیریت ترافیک Replication است. از آنجایی که سرعت لینک در یک سایت بالا فرض می شود، Replication در یک سایت برای حداکثر سرعت و کمترین نا پیدایی بهینه سازی شده است. نا پیدایی عبارت است مدت زمانی که طول می کشد تا یک شیئ ساخته شده در یک دامین کنترلر در سایر دامین کنترلر های همان سایت از طریق Replication ساخته شود. اما زمانی که سرعت لینک (ها) کم باشد، استفاده بهینه از پهنای باند موجود مهمترین مسئله است. با استفاده از ساختن سایت ها می توانیم، با استفاده از تکنیک های فشرده سازی و زمان بندی کردن Schedule کردن، ترافیک Replication را به بهینه ترین شکل ممکن دربیاوریم.

ادامه نوشته

Replication – 1

معمولا در محیط اکتیو دایرکتوری بیش از یک Domain Controller وجود دارد. ساده ترین روش برای بالابردن Availability سرویس نیز راه اندازی چند DC است. ممکن است که تمام سرور ها در Data Center سازمان باشد، یعنی جایی که ارتباطات شبکه بسیار پر سرعت هستند، همچنین ممکن است سرور ها در کشور های متمایزی باشند که معمولا در این حالت سرعت link نا کافی است.

ادامه نوشته

آشنایی با Snap-in های Active Directory

اکثریت قابل توجه عمل های مدیریتی توسط کنسول های زیر در مدیریت AD DS صورت می گیرد:

- Active Directory Users and Computers : این کنسول، کنسولی است که کارهای روزانه مدیریتی در آن صورت می گیرد. مدیریت اشیاء همچون User، Group و Comptuers در این کنسول صورت می گیرد و می توان گفت حجیم ترین اعمال مدیریتی در این کنسول صورت خواهد گرفت. تمام مدیران شبکه معمولا بر این کنسول تسلط دارند.

-  Active Directory Sites and Services : مدیریت Replication ، Network Topology و سرویس های مرتبط با آن ها در این کنسول صورت می گیرد.

-  Active Directory Domians and Trusts : مدیریت Domain Functional level و ارتباطات Trust و سایر موارد مرتبط در این کنسول صورت می گیرد.

- Active Directory Schema : بررسی و ویرایش مشخصات کلاس های اشیاء و ویژگی های آن ها در این کنسول صورت می گیرد.

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

ادامه نوشته

مرحله بندی نصب RODC

همانطوری که پیش تر اشاره شد، RODC برای شعبی از سازمان طراحی شده است که از دیدگاه پشتیبانی IT ضعیف می باشند و یا امنیت لازم جهت قرار دادن یک DC خواندنی – نوشتنی وجود ندارد. حال با توجه به این شرایط چگونه باید یک RODC را در شعبه راه اندازی کرد؟ برای حل این مسئله از نصب به صورت مرحله بندی شده (Staged) استفاده می شود. این فرآیند دو مرحله است:

ساخت یک اکانت برای RODC به صورت Prestaged

یکی از اعضای Domain Admins یک اکانت برای RODC در Active Directory ایجاد کند. برای این منظور درکنسول Active Directory Users & Computers روی Domain Controller OU کلیک راست کرده و گزینه ی Pre-Create Read-Only Domain Controller را می زنیم. یک Wizard بسیار مشابه با Wizard نصب آغاز می شود که در آن مواری همچون Site و PRP قابل تنظیم است.

ادامه نوشته

Kerberos – قسمت اول: اسطوره

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

پروتکل Kerberos توسط MIT توسعه داده شده است. ورژن های ۱ تا ۳ این پروتکل به صورت داخلی در خود MIT مورد استفاده قرار گرفته بودند. ورژن ۴ این پروتکل در دهه ۸۰ منتشر شد. در ۱۹۹۳ در RFC 1510 و سپس در ۲۰۰۵ در RFC 4120 نسخه ۵ام این پروتکل معرفی شد. MIT یک نسخه رایگان و دارای حق تالیف از این پروتکل را عمومی کرد و اسپانسر های مختلفی همچون Microsoft, Apple, Google, Oracle و سازمان های بزرگ دیگری پیدا کرد. در آن زمان، از آنجایی که از الگوریتم رمزنگاری DES استفاده می کرد، مجوز صادر شدن آن به خارج از آمریکا وجود نداشت. Microsoft در Windows از این پروتکل با قدری ویرایش استفاده می کند. Windows Server 2008 از نسخه ای کاملا منطبق بر RFC 1510 استفاده می کند.

Kerberos یک پروتکل تشخیص هویت (Authentication) در شبکه است. Windows Server 2000/2003/2008 از این پروتکل به عنوان پروتکل اصلی تشخیص هویت برای Active Directory استفاده می کنند. پروتکل دیگری که در Active Directory جهت Authentication استفاده می شود، NTLM است که جهت سازگاری با نسخ قبلی به کار گرفته شده است. Realm محدوده ای است که Kerberos در آن قادر به Authentication است.

ادامه نوشته

Kerberos- قسمت دوم: Active Directory

در محیط Active Directory وظیفه KDC ها بر عهده ی Domain Controller ها است همچنین از Domain برای Realm استفاده می شود. در اینجا قصد داریم، فرآیند ذکر شده برای Kerberos v5 را در محیط Active Directory مرور کنیم.

بخش یک

 

ادامه نوشته

Kerberos – قسمت سوم: پیکربندی

همانطور که پیش تر اشاره شده، Kerberos پروتکل پیش فرض برای تشخیص هویت کاربران کلاینت های ویندوز ۲۰۰۰ به بعد می باشد. موارد متعددی در خصوص Kerberos را می توان پیکربندی کرد. برای دسترسی به این تنظیمات به Group Policy Managment Console رفته و اقدام به ویرایش Group Policy در محدوده ی مناسب کنید. به عنوان مثال ویرایش Default Domain Policy. گزینه های در دسترس عبارت اند از:

ادامه نوشته

Replication روی Firewall

زمانی که از یک ساختار توزیع شده (distributed) برای زیرساخت Active Directory Domain Services استفاده می شود، با چالش قابل توجه در رو به رویی با Firewall ها پدیدار می شوند:

۱. promote کردن ابتدایی DC ها.

۲. ترافیک Replication بین DC ها.

Active Directory به پروتکل RPC یا Remote Procedure Call برای replication بین dc ها وابسته است هر چند در برخی شرایط با پذیرش محدودیت در توانایی Replication کردن برخی پارتیشن ها، می توان از SMTP یا Simple Mail Transfer Protocol استفاده نمود. همانطور که می دانید، سیستم تخصیص پویای پورت RPC یک عدد تصادفی بالای ۱۰۲۴ به عنوان شماره پورت انتخاب می کند. برای کارکرد صحیح زیرساخت AC DS یکی از راهکار های زیر با توجه به معماری DMZ پیشنهاد می شود:

۱. اجازه دادن به RPC در Firewall روی Port address Range مورد استفاده Dynamic Port Allocation (باز کردن پورت های مورد نیاز).

۲. محدود کردن RPC در استفاده از پورت های TCP و باز کردن همان تعداد.

۳. کپسوله کردن ترافیک DC به DC با استفاده IPSec و باز کردن Firewall برای آن.

ادامه نوشته

نصب AD DS از روی Media

برای نصب Active Directory Domain Services می توان از یک Installation Media استفاده کرد. کاربرد این روش کاهش ترافیک Replication اولیه بین DC جدید با DC های قبلی است. با استفاده از ابزار ntdsutil.exe می توان یک Installation Media برای Additional Domain Controller در یک دامین موجود استفاده کرد. این متد به شما امکان می دهد تا DC ها در سایت های دیگر را بهینه تر راه اندازی کنید.  به این روش به اختصار IFM گفته می شود. (Installation From Media)

موضوع Installation From Media یا IFM قابلیت جدید در Windows Server 2008 نیست اما روش جدیدی برای انجام آن وجود دارد. با توجه بهبود NTDS Utility، یکی از موضوعات بهبود یافته، IFM است. هرچند مطابق گذشته می توان با استفاده از System State Backup این عمل را انجام داد؛ اما به به صورت عادی؛ یک System State Backup حاوی اطلاعات بیشتری نسبت به آنچه برای IFM نیاز داریم می باشد. از سوی دیگر با توجه به قابلیت های جدید، همانند RODC روش قبلی استفاده از System State Backup کارا نخواهد بود. بدیهی است که می توانید با استفاده از یک دامین کنترلر ۳۲ بیتی یک Media برای IFM روی دامین کنترلر ۶۴ بیتی و بر عکس ایجاد کنید. از این رو با چالشی رو به رو نیستیم.

ادامه نوشته

مرحله بندی نصب RODC

همانطوری که پیش تر اشاره شد، RODC برای شعبی از سازمان طراحی شده است که از دیدگاه پشتیبانی IT ضعیف می باشند و یا امنیت لازم جهت قرار دادن یک DC خواندنی – نوشتنی وجود ندارد. حال با توجه به این شرایط چگونه باید یک RODC را در شعبه راه اندازی کرد؟ برای حل این مسئله از نصب به صورت مرحله بندی شده (Staged) استفاده می شود. این فرآیند دو مرحله است:

ادامه نوشته

Global Catalog Replication

Global Catalog یا به اختصار GC با تمام partition های دیگر متمایز است و از این رو، پروسه ها مربوط به آن با سایر Partition ها قدری متفاوت و خاص است. GC به خودی خود Read-Only است و از این بابت است که اطلاعات آن مستقیما توسط Administrator قابل ویرایش نیست. همانطور که پیش تر گفته شده بود، GC در واقع لیستی از برخی مقدار ویژگی (Attribute) مربوط به isMemberOfPartialAttributeSet آن ها True است. به عبارت دیگر، GC خود از روی Active Directory Data Store ساخته می شود.

هر GC Server باید اطلاعات GC را از تمام DC ها در سراسر Forest به دست آورد. برای درک این مسئله با استقاده از دو مثال توضیح داده خواهد شد که  Connection Object ها برای GC به چه ترتیبی ساخته می شوند.

ادامه نوشته

ویژگی های جدید DNS

Microsoft DNS Server با آنکه با RFC های مرتبط به DNS که توسط Internet Engineering Task Force یا به اختصار IETF منتشر شده است، سازگار است دارای ویژگی های منحصر به فردی برای سرویس های NOS یا Network Operationg Syste مخصوص مایکروسافت است که تحت AD DS فعال می گردند. همانطور که می دانید، در یک Active Directory integrated Zone محل ذخیره سازی اطلاعات حتی تغییر می کند و قابلیت Secure DDNS در دسترس قرار می گیرد. جهت پشتیبانی از RODC ها، یک نسخه Primary فقط خواندنی طراحی شده که روی RODC ها قرار گیرد.

در +Windows Server 2008 R2 قابلیت background zone loading اضافه شده است که این ویژگی سبب می شود سرعت boot شدن سرور افزایش یابد. پیش از شروع سرویس دهی DNS Server نیاز است تمام رکورد ها load شوند. اگر یک سرور دارای Zone های متعدد با تعداد رکورد های بالایی باشد، زمان لازم قابل توجه خواهد بود. در یک گام برای حذف WINS Server از شبکه ها ویژگی جدید GNZ به DNS اضافه شده است تا بتواند از اسامی تک سیلابی پشتیبانی کند.

جهت افزایش محافظت در برابر Spoofing سرویس DNS از قابلیت Global Query Block List بهره می برد. توسط این قابلیت جدید، زمانی که کلاینت ها از پروتکل هایی همانند Web Proxy Automatic Discovery یا WPAD یا Intra-site Automatic Tunnel Addressing Protocol یا به اختصار ISATAP  و از DNS جهت Resolve کردن اسامی استفاده می کنند می تواند برای کاربرانی که از قابلیت Dynamic Update بهره می برند مخاطره انگیز باشد.

ادامه نوشته

آشنایی با DNS–قسمت سوم

Aging و Scavenging

Aging به فرآیندی گفته می شود که در آن با استفاده از Timestamp، طول عمر Resource Record هایی که به صورت Dynamic در DNS اضافه شده اند معین می گردد. Scavenging به فرآیندی گفته می شود که در آن Resource Record هایی که عمر آن ها سپری شده است، حذف می گردند. بدیهی است Scavenging زمانی می تواند عمل کند که Aging عمل می کند. این فرآیند سبب می شود تا Resouce Record ها دارای تعداد مدیریت شده ای باشند زیرا نود هایی که از شبکه خارج شده اند پس از مدتی Resource Record های مربوط به آن ها حذف می شود و حجم داده های DNS Server نیز مدیریت می شود.

ادامه نوشته

Active Directory Data Storage

پایگاه داده (Database) اکتیو دایرکتوری یک فایل به نام ntds.dit است که به صورت پیش فرض در %systemroot%\ntds قرار دارد. این folder همچنین شامل فایل های زیر است:

- Edb.chk: این فایل یک Checkpoint است که در واقع مشخص می کند کدام تراکنش ها (Transaction) در log file روی Active Directory Database نوشته شده است.

- Edb.log: این فایل، یک Log File برای Transaction اخیر است و اندازه ثابت ۱۰MB را دارد.

- Edbxxxxx.log: پس از آنکه Active Directory برای مدتی اجرا گردد، یک یا چند نمونه از این فایل ها ایجاد خواهد شد. xxxxxx یک عدد هگزادسیمال است. زمانی که Current Transaction Log File، پر شود، به چنین فرمتی تبدیل نام خواهد شد و فایل جدید Edb.log ایجاد خواهد شد.

ادامه نوشته

Active Directory Database Maintenance

یکی از قابل توجه ترین مدیریت ها روی Active Directory مدیریت Data Store و به خصوص Database Maintenance (نگه داری پایگاه داده) است. در شرایط عادی، نیاز به مدیریت مستقیم وجود ندارد زیرا مکانیسم های خودکار، به خوبی می توانند عملیات نگه داری از پایگاه داده را انجام دهند. با این وجود در شرایط خاص، ممکن است با استفاده از ابزار ntdsutil نیاز به مدیریت مستقیم وجود داشته باشد. در ادامه ابتدا روش های خودکار توضیح داده می شود و سپس روش استفاده از این ابزار جهت Database maintenance شرح داده خواهد شد.

ادامه نوشته

حذف کردن یک DC

با استفاده از دستور DCPromo.exe می توانید یک DC را حذف کنید. زمانی که DC در وضعیت نرمال به شبکه متصل است و آن را حذف می کنید، Meta-Data های خود را از روی Directory حذف می کند و یا به عبارت دیگر، در دایرکتوری اثر قابل توجهی بر جای نمی گذرد. می توانید از یک Answer File نیز برای حذف DC استفاده کنید:

[DCINSTALL]
UserName=DOMAIN\username (in Administrators group of the domain)
UserDomain=FQDN of user specified by UserName
Password=password for user specified by UserName
AdministratorPassword=password will be assigned to local Administrator
RemoveApplicationPartitions=yes
RemoveDNSDelegation=yes
DNSDelegationUserName=DOMAIN\username with permissions to remove DNS delegation
DNSDelegationPassword=password for the account

ادامه نوشته

نصب Additional Domain Controller

همانطور که پیش تر اشاره شد، اکیدا توصیه می شود در هر دامین حداقل دو دامین کنترلر وجود داشته باشد. پیش از نصب یک Additional Domain Controller یا به اختصار ADC ابتدا لازم است در خصوص سایت ها، GC، DNS Server و همچنین موضوعات امنیتی مد نظر قرار گیرند. همچنین در صورتی که محدودیت در ترافیک Replication وجود داشته باشد لازم است راهکاری جهت Replication اولیه مد نظر قرار گیرد. در ادامه یک ADC را روی Windows Server 2012 نصب می کنیم. مراحل نصب بسیار مشابه با نصب اولین دامین کنترلر در یک جنگل جدید است.

در ویزارد نصب، در قسمت Deployment Configuration گزینه Add a Domain Controller to an Existing Domain را انتخاب می کنیم و نام دامین را وارد می کنیم. همچنین لازم است یک Credential با سطح دسترسی مناسب انتخاب کنیم.

ادامه نوشته

AD DS Disaster Recovery

AD DS احتمالا حساس ترین سرویس روی شبکه است. اگر اختلالی در زیرساخت اکتیودایرکتوری ایجاد شود، می تواند سبب شود تا کاربران به بسیاری از سرویس های دیگر روی شبکه نتوانند دسترسی پیدا کنند. از این روی، لازم است تا حداقل سطحی از Disaster Recovery و preventionکه برای سایر اجزای شبکه در طراحی می گردد برای AD DS نیز به کار گرفته شود. نکات کوچک زیر، با آنکه ابتدایی هستند در برخی شبکه های سازمانی مورد توجه قرار نگرفته اند.

- در فاز طراحی لازم است، نرم افزارها و سخت افزار های مورد نیاز جهت Backup تعیین کردد و همچنین برنامه ای مناسب برای آن معین گردد. طراحی Backup لازم است، آزمایش گردد و سپس به صورت مستحکم اجرا گردد. همچنین پیش از تغییرات قابل توجه، همانند ویرایش Schema لازم است backup انجام گردد.

- تمام Domain Controller ها لازم است از سخت افزار مناسب و redundant استفاده کنند. در بسیاری از سازمان های برای DC ها علاوه بر Redundant Network Links از دو مدار تغذیه برق برای هر کدام از power supply های سرور استفاده می شود.

ادامه نوشته