مدیریت های اولیه در AD DS

 

تذکر در خواندن این مطلب : پیش از خواندن این بخش، خواننده لازم است با Microsoft Management Console یا به اختصار MMC آشنایی داشته باشد. همچنین لازم است  با مفاهیم اولیه Users ، Computers و Groups آشنایی داشته باشد. ممکن است برخی از موارد در مطلب پوشش داده شده باشد اما صرفا جهت یادآوری ذکر شده اند و چنانچه خواننده با موارد ذکر شده آشنایی کافی نداشته باشد ممکن است با شبهاتی مواجه گردد.

آشنایی با Snap-in های اکتیو دایرکتوری

اکثریت قابل توجه عمل های مدیریتی توسط کنسول های زیر در مدیریت 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 : بررسی و ویرایش مشخصات کلاس های اشیاء و ویژگی های آن ها در این کنسول صورت می گیرد.

در زمان نصب Active Directory کنسول های فوق در Administrative Tools نصب می گردند. در Core Server توجه داشته باشید توصیه می شود به مدیریت از راه دور بپردازید و استفاده از ابزار Remote Administration می تواند نقش مهمی در کمک به مدیریت از راه دور داشته باشد. می توانید کنسول های مورد نظر خود را در MMC همان گونه که می پسندید آماده کنید. با این حال دو Snap-in که استفاده بیشتری دارند در Server Manager زمانی که AD DS نصب شود قابل دسترسی خواهد بود. Snap-in های Active Directory Users and Computers و Active Directory Sites and Services. جهت مدیریت اکتیو دایرکتوری از راه دور همچنین می توانید از RSAT که روی کلاینت های Windows Vista SP1 به بعد قابل نصب است استفاده کنید. همچنین برای Window Server 2008 R2 استفاده از Active Directory Administration Center بسیار کمک کننده و راحت است. به هر صورت توانایی کار با تمام ابزار های ذکر شده در این قسمت برای هر مدیر شبکه ای لازم است. در اینجا فرض می شود، خواننده با کار عملی در این قسمت می تواند مهارت های لازم را به دست آورد از توضیحات مربوطه صرف نظر می گردد.

تصویر 1: Active Directory Administrative Centers

جهت دسترسی به کنسول های فوق راه های مختلفی در دسترس است. یکی از ساده ترین آن ها مراجعه به Administrative Tools موجود در Control Panel است. به مرور زمان با راه های متفاوتی آشنا خواهیم شد. برای دسترسی ساده تر به Administrative Tools می توانید نمایش دادن آن را در Start Menu در Taskbar and Start Menu تنظیم کنید.

در ادامه به ساخت اشیاء اولیه ای که جهت مدیریت لازم اند پرداخته می شود.

ساخت یک Organizational Unit

OU ها Container های مدیریتی در اکتیو دایرکتوری هستند که برای جمع آوری کردن اشیایی که دارای الزامات مشترکی هستند به کار می روند. پیش تر در خصوص مفهوم OU بحث شد اما زمانی که در آینده با کاربرد های OU و سپس با نحوه طراحی OU آشنا شوید موضوع OU ها روشن تر خواهد شد. فعلا چنین تصور می کنیم،همانند Folder ها که برای مدیریت ساده تر روی فایل ها استفاده می شوند، OU ها برای مدیریت ساده تر در یک ساختار سلسله یافته روی برخی اشیاء موجود در اکتیو دایرکتوری به کار می روند. در اینجا لغت مدیریتی بسیار مهم است چرا که عضو یک OU بودن بدون هیچ اقدام مدیریتی روی OU هیچ حق یا دسترسی خاصی را برای شیئ ایجاد نخواهد کرد.  برای ساخت یک OU به صورت زیر عمل می کنیم.

1. به کنسول Active Directory Users and Computers رفته و روی گره نام دامین (Domain Node) در ساختار درختی کلیک راست کرده.

2. از منوی New گزینه New را انتخاب کرده و Organizational Unit را انتخاب می کنیم.

3. نام OU مورد نظر را انتخاب می کنیم. اکیدا توصیه می شود از اسامی با معنا و بر اساس چارت سازمانی سازمان مطبوع استفاده گردد. ممکن است طراحی OU ها تطبیق دقیقی با چارت سازمانی نداشته باشد، در این شرایط نیز توصیه می شود مربوط ترین نام ممکن را انتخاب کنید.

4. روی OK کلیک کنید و OU مورد نظر ساخته می شود. برای تنظیم موارد مرتبط روی OU ساخته شده کلیک راست کرده و properties را بزنید. اکنون می توانید موارد مختلفی را تنظیم کنید.

5. می توانید در یک OU یک یا چند OU دیگر بسازید. برای این منظور روی OU مطلوب کلیک راست کرده و 2 تا 4 را انجام دهید. توجه داشته باشید که امکان انتقال با Drag & Drop موجود است.

تصویر 2:  منوی New

در ابزار های مدیریتی Window Server 2008 یک ویژگی جدید به نام Protect Container From Accidental Deletioan اضافه شده است.. این ویژگی که بسیار قابل توجه است، در اینجا سبب می شود تا دو Permission جدید به OU ها اضافه شود. این مجوز ها به این شرح اند:

1. Everyone::Deny::Delete

2. Everyone::Deny::Delete Subtree

و این به معنای این است که هیچ مدیری نمی تواند به صورت تصادفی یک OU را حدف کند. اکیدا توصیه می شود از این ویژگی در تمام OU ها استفاده شود و از غیر فعال نمودن همیشگی آن اکیدا خودداری شود هر چند شاید چندان خوش آمد نباشد.

برای حذف یا هر عملی که موجب حذف شدن OU می شود همانند انتقال باید:

1. در کنسول Active Directory Users and Computers از منوی View گزینه Advanced Features را فعال کنید و روی OU مورد نظر کلیک راست کنید.

2. در زبانه ی Object چک باکس Protect Object from Accidental Deletion بدون چک کنید.

3. پس از اقدامات مدیریتی لازم دوباره گزینه را چک بزنید.

تصویر 3: ویژگی protect Object from accidental deletion

ساخت یک شیئ User

مهمترین و ابتدایی ترین شیئ که پس از نصب اکتیو دایرکتوری مورد بررسی قرار می گیرد، User یا کاربر است. هر چند دومین قدم در مراحل عملیاتی سازی محیط اکتیو دایرکتوری و حتی شاید مدیریت کاربران نباشد. برای مدیریت محیط اکتیو دایرکتوری از کنسول ها و Snap-in های متعددی استفاده می شود. کنسولی که بیشترین استفاده روزانه را دارد و بیشترین حجم کاری مدیر شبکه روی آن کنسول اتفاق می افتد کنسولی به نام Active Directory Users and Computers است که از طریق MMC یا روش های مشابه می توانید به آن دسترسی پیدا کنید. برای باز کردن کنسول در یک روش ساده می توانید روی DC در run وارد کنید dsa.mcs. چنانچه از Core Server استفاده می کنید، توصیه می شود به صورت remote به DC متصل شده و به مدیریت بپردازید هر چند که در آینده روش افزودن یک user از روی خط فرمان مورد بررسی قرار می گیرد.

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

1. در Administrative Tools در Control Panel کنسول Active Directory Users and Computers را باز کنید.

2. در نوار سمت چپ، روی نام دامین مثلا Contoso.com دابل کلیک کنید تا ساختار درختی آن باز شود.

3. روی Users کلیک کرده تا User های موجود را مشاهده کنید.

4. برای ساخت یک کاربر جدید روی Users کلیک راست کرده و New > New User را بزنید.

5. در ویزارد باز شده با توجه به موارد زیر فیلد ها را پر کنید.

- در واقع فیلد Initials مربوط به نام وسط می شود.

- نام کامل برای ویرایش آسان تر است و در واقع CN کاربر است. این قسمت در کنسول نمایش داده می شود. باید در دربرگیرنده ی خود یکتا باشد. به عنوان مثال تنها یک کاربر با نام کامل معین می تواند در یک OU باشد. در تشابهات اسمی می توانید نام کامل را به نحوی ویرایش کنید که بتوانند هر دو کاربر ساخته شوند.

- در قسمت logon name نامی که کاربر باید با آن وارد سیستم شود را معین می کنید و با استفاده از لیست drop-down پسوند UPN را که در ادامه ی نام انتخابی شما می آید را انتخاب می کنید. این پسوند با استفاده از کاراکتر “@” به بقیه نام متصل می شود. در اکتیو دایرکتوری شما می توانید از کارکتر هایی همانند – یا ‘ برای logon name استفاده کنید اما در بسیاری از نرم افزار ها محدودیت کارکتر های خاص بیشتر است بنابراین توصیه می شود از کارکتر های خاص استفاده نکنید.

- لیست پسوند های UPN می تواند از طریق کنسول Active Directory Domains & Trusts قابل تعیین است که در اینجا مورد بحث قرار نمی گیرند اما نام DNS دامین همیشه در دسترس قرار دارد و نمی توان را حذف کرد.

- در قسمت logon name ویندوز های قبل 2000 محدودیت تعداد کارکتر بیشتر است و بعدا در این خصوص توضیح داده خواهد شد.

6. next را بزنید و در مرحله بعدی کلمه عبور اولیه و تنظیمات ساده ای را می توان انجام داد.

- اکیدا توصیه می شود به علت پیگیری های وقایع و یافتن عامل خطا های انسانی، کلمه عبور یکسانی برای کاربران در حال ساخت تعیین نکنید و گزینه user must change password at next logon را فعال کنید تا کاربر با تعویض کلمه عبور خود، مسئولیت فعالیت های خود را نتواند به دپارتمان IT یا مدیر شبکه حواله کند.

- پسورد اولیه باید شرایط تعیین شده در Group Policy را دارا باشد به صورت پیش فرض باید دارای Complexity باشد که دارای شرایط زیر است

آ. بیش از 7 کاراکتر یا 7 کاراکتر

ب. باید شامل سه یا چهار نوع (دسته) کاراکتر متفاوت باشد؛ شامل حروف کوچک، حروف بزرگ، اعداد و کارکتر های غیر الفبایی همانند – % # ! $

ج. نمی تواند شامل هیچ کدام از نام ها یا logon name ها باشد

7. Next را بزنید و اطلاعات وارد شده را بازبینی کنید. در صورتی که اشکالی موجود نبود Finish را بزنید.

8. با کلیک راست کردن روی User ساخته شده می توان موارد متعددی را ویرایش کرد که در آینده مورد بررسی قرارمی گیرند.

تصویر 4: User Properties

ساخت یک شیئ Group

گروه ها کلاس مهمی از اشیاء اکتیو دایرکتوری هستند. گروه های Container هایی هستند که برای جمع آوری کاربران استفاده می شوند. به این طریق، به جای مدیریت مستقیم روی کاربران، به مدیریت روی گروه ها می پردازیم. یکی از موارد پر کاربرد می تواند مجوز های دسترسی به Shared Folder ها باشد. برای ساخت گروه:

1. کنسول Active Directory User and Computers را باز کنید و به Container مورد نظر خود مثلا OU مربوطه رفته و کلیک راست کنید.

2. در منوی New گزینه group را بزنید. سپس در پنجره New Object – Group ابتدا نام گروه را وارد کنید. توجه داشته باشید اکثر سازمان ها رویه خاصی برای نام گذاری گروه ها دارند که باید از آن رویه پیروی کنید. اکیدا توصیه می شود نام گروه در pre-windows2000 را تغییر ندهید و همان نام پیش فرض که مطابق نام گروه است رها کنید.

3. برای تعیین نوع گروه در نظر داشته باشید:

الف: گروه Security : گروه هایی هستند که برای اهدای مجوز های لازم به کاربر به کار می روند. از این گروه همچنین می توان به عنوان لیستی جهت E_mail استفاده کرد.

ب: گروه Distribution : گروه هایی هستند که صرفا برای لیستی جهت E_mail به کار روند و نمی توان هیچ مجوز دسترسی خاصی برای آن ها استفاده کرد.

4. برای تعیین حوزه گروه در نظر داشته باشید:

الف: Domain Local : گروهی است که معرف و شامل کاربران و گروه هایی است که دسترسی یکسانی به یک یا چند منبع نیاز دارند.. به عنوان مثال گروهی که باید بتواند نتایج یک پروژه را ویرایش کند.

ب: Global : گروهی است که معرف و شامل کاربران و گروه هایی است که بر اساس موضوعی همانند نوع کار، موقعیت و موارد مشابه اشتراک دارند.

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

توجه داشته باشید که Group Scope در آینده به تفصیل بررسی می شود. همچنین توجه داشته باشید در دامین هایی که Functional Level آن ها Mixed یا Interim است تنها می توانید گروه Domain Local یا Global برای Security Group بسازید.

5. OK را بزنید و سپس با راست کلیک روی Group ساخته شده می توانید موارد بیشتری را در تکمیل کنید. توجه داشته باشید که Description از آنجایی که به صورت پیش فرض در کنسول نمایش داده می شود امکان مناسبی برای توضیح در خصوص گروه، دلایل یا شرایط گروه است.

تصویر 5: Group Properties

ساخت یک شیئ Computer

کامپیوتر ها در اکتیو دایرکتوری مشابه کاربر ها دارای یک اکانت هستند. در واقع کامپیوتر ها هم در اکتیو دایرکتوری همان طوری که یک کاربر logon می کند، logon می کنند. در آینده در خصوص اکانت های کامپیوتر بسیار خواهیم آموخت اما در اینجا برای ساخت یک اکانت کامپیوتر:

1. در کنسول Active Directory Users and Computers روی گره Computer یا گره مورد نظر همانند OU، در ساختار درختی کلیک راست کنید و گزینه New و سپس Computer را بزنید.

2. در قسمت Computer Name نام کامپیوتر را وارد کنید. اکیدا توصیه می شود نام Pre-2000 را تغییر ندهید.

3. در قسمت user or group باید کاربر یا گروهی که می تواند کامپیوتر را عضو دامین کند را انتخاب کنید. معمولا باید Support Team انتخاب شود. می توان کاربری که کامپیوتر به او اختصاص دارد را انتخاب کرد. در آینده در خصوص راهکار های عضویت کامپیوتر ها در دامین بحث خواهد شد.

4. چک باکس Assign this computer account as a pre-windows 2000 computer را چک نزنید مگر آنکه سیستم عامل کلاینت ویندوز NT 4.0 یا قبل از آن باشد.

5. پس از ایجاد می توانید درproperties مربوطه گزینه های بیشتری را تکمیل نمایید. توجه داشته باشید که پس آنکه کامپیوتر عضو دامین شد، اطلاعاتی نظیر DNS name یا سیستم عامل به صورت خودکار تکمیل می شوند و قابل ویرایش نیستند.

تصویر 6: ساخت یک اکانت کامپیوتر جدید

با تشکر از سایت پورت ۸۰ به آدرس http://www.erfantaheri.com

امنیت روابط Trust

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

Authenticated Users

یک رابطه Trust به تنهایی دسترسی به منابع ایجاد نمی کند، با این وجود کاربران در دامین اعتماد شده بلافاصله به برخی از منابع دسترسی پیدا می کنند. دلیل این امر آن است که در ACLs بسیاری از موارد از طریق گروه کاربران Authenticated Users مجوز دار شده اند.

عضویت در گروه های کاربری دامین

بهترین روش برای مدیریت کاربران و سطوح دسترسی آن ها قرار دادن کاربران در گروه های کاربری است. کاربران باید در گروه ها قرار گیرند و دسترسی کاربران از روی گروه هایی که عضو است مشخص گردد. بهترین روش مدیریت کاربران دامین اعتماد شده (در صورت تعدد کاربرانی که نیاز به دسترسی به منابع مختلف دارند) آن است که گروه های Global آن ها عضو گروه های دامین اعتماد کننده شوند.

ACLs

امکان اضافه کردن کاربران یا گروه های Global به صورت مستقیم در ACLs موجود است. این روش به مناسبی عضویت در گروه های کاربری دامین نیست اما امکان پذیر است و در محیط های کوچک کفایت می کند.

transitivity و Realm Trust

در زمان ساخت Realm Trust توجه داشته باشید که به صورت غیر Transitive یا بدون خاصیت تعدی به صورت پیش فرض Trust ساخته می شود. اگر رابطه را Transitive کنید، تمام کاربرانی که در Realm و Domain های اعتماد شده ی Realm اعتماد شده شما قرار دارند مورد اعتماد خواهند بود و پتانسیل دسترسی به منابع را خواهند داشت. از این رو اکیدا توصیه می شود روابط Realm Trust به صورت غیر Transitive باشند.

SID Filtering یا Domain quarantine

به صورت پیش فرض SID Filtering در تمام روابط External Trust و Forest Trust فعال است. زمانی که یک کاربر در دامین اعتماد شده، Authenticate می شود، کاربر اطلاعات همچون SID و SID های گروهایی که در آن عضو است را در تیکت خود داراست.

برخی از SID هایی که در تیکت کاربر است ممکن است توسط Domian اعتماد شده ساخته نشده باشند. به عنوان مثال در سناریوی انتقال اشیاء ممکن است SIDHistory دارای SID هایی باشد که بدون شک توسط دامین مقصد (دامین اعتماد شده) ساخته نشده اند. در این حالت ممکن است کاربر به منابعی از طریق SIDHistory خود دسترسی داشته باشد.در سناریوی روابط Trust دو دامین، ممکن است کاربر بدون داشتن دسترسی های Administrator، دسترسی Administrator پیدا کند.

با استفاده از SID Filtering می توان از بروز مشکلات بسیاری جلوگیری کرد. با استفاده از این روش SID هایی که SIDهای اصلی کاربر نیستند فیلتر می شوند. هر SID شامل SID دامینی است که از آن نشات گرفته است، بنابراین وقتی که کاربر لیست SID ها را در تیکت ارائه می دهد، SID Filtering آن ها را بررسی می کند و از دامین اعتماد شده می خواهد که تمام SID هایی که منشاء آن دامین اعتماد شده نباشند را دور بریزد. استفاده از SID Filtering اکیدا توصیه می شود اما در صورتی که می خواهید کاربران با استفاده از SIDHistory خود بتوانند به منابع دسترسی داشته باشند لازم است تا SID Filtering غیر فعال گردد.

برای غیر فعال کردن SID Filtering دستور زیر را وارد کنید:

netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:no

و برای فعال کردن به جای مقدار no در سوییچ quarantine مقدار yes را قرار دهید.

توجه داشته باشید که مثال SIDHistory تنها یک مورد از موارد تاثیر SID Filtering است.

حالات Authentication

با ساختن یک رابطه ی External Trust یا Forest Trust، امکان تنظیم Scope تشخیص هویت (Authentication) نیز وجود دارد. دو حالت برای Authentication موجود است:

- Selective Authentication
- Domain-Wide Authentication برای External و Forest-Wide Authentication برای Forest

اگر Domain-wide یا Forest-wide انتخاب شود، تمام کاربران در دامین اعتماد شده، می توانند برای دسترسی به منابع در دامین اعتماد کننده مورد Authenticate قرار بگیرند. در نظر داشته باشید تمام کاربران در دامین اعتماد شده، Authenticated Users در نظر گرفته می شود و ممکن است به برخی از منابع بلافاصله دسترسی پیدا کنند. جهت استفاده از این حالت لازم است اطمینان نسبی نسبت به وضعیت امنیتی داشته باشید.

اگر Selective Authentication انتخاب شود، تمام کاربران در دامین اعتماد شده، دارای هویت های قابل اعتماد هستند. اما آنها تنها برای سرویس ها و منابعی که معین شده است حق دسترسی دارند. برای تنظیم کردن Authentication Mode در یک رابطهOutgoing ابتدا Properties مربوط به دامین اعتماد کننده را در کنسول Active Directory Domain and Trusts باز کرده و سپس ارتباط Trust مورد نظر را انتخاب و Properties مربوطه را باز کردن و در tab (زبانه) Authentication می توانید حالت مطلوب را معین کنید.

پس از انتخاب Selective Authentication دیگر هیچ کاربر مورد اعتمادی نمی تواند به منابع دسترسی داشته باشد مگر آنکه مجوز های مربوطه را داشته باشد. برای این منظور در کنسول Active Directory Users and Computers رفته و از منوی View ویژگی Advanced Features را فعال کنید. سپس Properties مربوط به کامپیوتری که کاربر از دامین اعتماد شده لازم است به آن دسترسی داشته باشد را انتخاب کنید. (مثلا File Server) در زبانه Security کاربر یا گروه کاربری مورد نظر را اضافه کرده و چک باکس Allow را چک بزنید. سپس لازم است کاربر مجوز های NTFS و Share Permission لازم جهت دسترسی به فایل را داشته باشد.

با تشکر از سایت پورت ۸۰ به آدرس  http://www.erfantaheri.com

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

 

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

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

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

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

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

در هر رابطه دو دامین نقش دارند:
1. دامین اعتماد کننده
2. دامین اعتماد شده

دامین اعتماد شده، دامینی است که هویت ها را در اطلاعات ذخیره شده خود ذخیره می کند و تشخیص هویت را انجام می دهد.

دامین اعتماد کننده، دامینی است که نمی تواند کاربر را تشخیص هویت کند زیرا اطلاعات را در اطلاعات ذخیره شده خود ندارد بنابراین به تشخیص هویت دامین اعتماد شد اعتماد می کند.

کاربران در دامین اعتماد شده می تواند به منابع در صورد داشتن مجوز دسترسی، دسترسی داشته باشند. همچنین می توانند حقوقی داشته باشند همانند اجازه Logon کردن روی کامپیوتر های دامین اعتماد کننده.

لغات ها در مبحث Trust شاید کمی گیج کننده باشند. درک رابطه trust با استفاده از دیاگرام بسیار ساده تر است. در دیاگرام زیر دامین A به دامین B اعتماد می کند. بنابراین دامین A دامین اعتماد کننده است و دامین B دامین اعتماد شده. اگر یک کاربر در دامین B بخواهد از دامین A استفاده کند، دامین A تشخیص هویت را با استفاده از رابطه Trust به دامین B واگذار می کند. همچنین دامین A می تواند از کاربران یا گروه های دامین B استفاده کند مثلا در دادن مجوز های دسترسی به منابع.

 

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

1. transitivity (خاصیت تعدی) : برخی از روابط Trust دارای خاصیت تعدی هستند البته همه رابطه ها دارای این خاصیت نیستند. با توجه به دیاگرام زیر خاصیت تعدی به این شکل تعریف می گردد. دامین A به دامین B اعتماد دارد. دامین B دامین C اعتماد دارد بنابراین دامین A به دامین C نیز اعتماد دارد. اگر Trust دارای خاصیت تعدی نباشد آنگاه دامین A به دامین C اعتماد ندارد. معمولا برای ایجاد اعتماد بین A و C از یک رابطه Trust جداگانه استفاده می گردد اما اگر Trust دارای خاصیت تعدی باشد این Trust جداگانه لازم نیست.

2. جهت (direction) : یک رابطه Trust می تواند یک طرفه یا دو طرفه باشد. در Trust به صورت یک طرفه یا one way کاربران در دامین اعتماد شده می توانند در دامین اعتماد کننده تشخیص هویت شوند اما عکس آن امکان پذیر نیست. در مثال فوق کاربران دامین B در دامین A تشخیص هویت می شوند اما کاربران دامین A در دامین B تشخیص هویت نمی شوند. در بسیاری از سناریو برای رسیدن به هدف رابطه دو طرفه (Two Way) می توان یک Trust دیگر با یک جهت متصاد Trust موجود ایجاد کرد.

3. اتوماتیک یا دستی: برخی از روابط Trust خودکار ساخته می شوند و برخی دیگر لازم است تا به صورت دستی ساخته شوند. در یک جنگل (Forest) تمام دامین ها به یک دیگر اعتماد دارند. به این دلیل که دامین هر Root Domain به Forest Root اعتماد دارد و هر Child Domain به parent Domain خود اعتماد دارد. این Trust ها به صورت خودکار ساخته می شوند و لازم نیست خاصیت تعدی یا جهت در آن ها در نظر گرفته شود.

پروتکل های تشخیص هویت و روابط Trust

ویندوز سرور 2003 با استفاده از دو پروتکل می تواند تشخیص هویت می کند: Kerberos V5 یا NT LAN Manager به اختصار NTLM و Kerberos V5 پروتکل پیش فرض در ویندوز های سرور 2008، 2003 و ویندوز های 7، Vista و XP است. اگر کامپیوتری در شبکه موجود باشد که از Kerberos V5 پشتیبانی نمی کند به جای Kerberos V5 از NTLM استفاده می شود.

تشخیص هویت Kerberos در یک دامین

به صورت بسیار مختصر؛ زمانی که کاربر به یک کلاینت تحت دامین و با پشتیبانی Kerberos تلاش می کند که Logon کند، درخواست تشخیص هویت برای Domain Controller ارسال می شود. هر Domain Controller همانند یک Key Distribution Center یا با اختصار KDC عمل می کند. پس از تایید هویت کاربر، KDC به کاربر های تایید شده یک Ticket-Granting Ticket یا به اختصار TGT می دهد. زمانی که کاربر نیاز دارد از یک منبع در همان دامین استفاده کند، ابتدا کاربر باید دارای یک Session Ticket معتبر برای آن کامپیوتری که منبع روی آن است داشته باشد. Session Ticket توسط KDC در Domain Controller فراهم می شوند. بنابراین کاربر درخواست Session Ticket خود را به Domain Controller می دهد. از آنجا که کاربر قبلا تشخیص هویت شده است دارای TGT است و TGT خود را برای نشانه ای این امر نمایش می دهد. این امر باعص می شود تا KDC بدون آنکه دوباره عمل تشخیص هویت را انجام دهد Session Ticket را به کاربر بدهد. Session Ticket احتیاج دارد تا سرور و سرویس مورد نظر معین شده باشد. KDC می تواند با استفاده از Service Principal Name یا SPN سرور درخواست شده در همان دامین سرویس را معین کند.

سپس کاربر می تواند با استفاده از Session Ticket خود به سرویس مطلوب متصل شود. سرور قادر است تا Session Ticket را بررسی کند و کنترل کند که کاربر تشخیص هویت شده است. این اتفاق با استفاده از Private Key انجام می شود. در هر صورت در اینجا قصد بررسی kerberos V5 را نداریم و در نهایت سرور با توجه به Trust داخل دامینی تشخیص هویت دامین که توسط دامین کنترلر انجام می شود را قبول دارد.

تشخیص هویت Kerberos در یک جنگل

هر Child Domain به Parent Domain خود Trust دارد و هر Tree Root به Forest Root نیز Trust دارد. این دو Trust از نوع Transitive و Two Way و اتوماتیک است. به Trust اول Parent-Child Trust و به Trust دوم Tree-Root Trust گفته می شود. درک Trust در یک جنگل از روی دیاگرام بسیار ساده تر از نوشتن این روابط است از این رو با توجه به دیاگرام زیر مطالب زیر را در نظر بگیرد.

به روابط Trust ساخته شده از روی Tree-Root Trust و Parent-Child Trust در اصطلاح Trust Path یا Trust Flow گفته می شود. در دیاگرام اول نمایی از DNS و در دیاگرام دوم نمایی از Trust Path به نمایش در آمده است. Tailspintoys.com در اینجا Forest Root است و Forest شامل دو Tree می باشد. اگر یک کاربر در USA.Windtiptoys.com بخواند یک Shared Folder روی EUROPE.Tailspintoys.com را ببیند تراکنش های زیر اتفاق می افتد.

1. کاربر روی کامپیوتر در USA.wingtiptoys.com ابتدا Logon می کند و توسط دامین کنترلر در دامین خود یعنی usa.wingtiptoys.com تشخیص هویت می شود. مراحل تشخیص هویت مشابه آن است که پیش تر گفته شد و کاربر یک TGT دریافت می کند.

کاربر می خواهد Shared Folder روی Europe.tailspintoys.com را ببیند.

2. کاربر به KDC روی دامین کنتر USA.wingtiptoy.com متصل می شود و درخواست Session Ticket می کند.

3. بر اساس SPN دامین کنترلر در USA.wingtiptoy.com متوجه می شود که سرویس مورد نظر روی دامین خود نیست. وظیفه KDC یک واسط بین کلاینت و سرویس است. از آنجا که سرویس Trust است اما در دامین خود نیست، KDC برای کمک به دسترسی به سرویس یک referral صادر می کند تا کاربر بتواند به Session Ticket مورد نظر خود دست پیدا کند.

KDC برای این کار یک الگوریتم ابتدایی دارد. اگر دامین KDC به صورت مستقیم با دامین سرویس Trust باشد، KDC به صورت مستقیم یک referral به دامین سرویس می دهد. اگر به صورت مستقیم Trust نباشد، Trust به صورت Transitive است بنابراین KDC یک Referral برای دامین بعدی در TRUST PATH صادر می کند.

4. از آنجا که usa.wingtiptoy.com مستقیما به europe.tailspintoy.com دارای Trust نیست، KDC یک referral برای دامین بعدی یعنی wingtiptoy.com صادر می کند.

5. کلاینت با KDC دامین ارجاع شده یعنی wingtiptoy.com ارتباط برقرار می کند.

6. بار دیگر KDC در wingtiptoy.com یک referral برای tailspintoy.com صادر می کند.

7. کلاینت با KDC در tailspintpy.com ارتباط بر قرار می کند و به europe.tailspintoys.com ارجاع داده می شود.

8. کلاینت به KDC در Europe.tailspintoys.com ارتباط برقرار می کند و از آنجا که Europe.tailspintoys.com به usa.wingtiptoys.com اعتماد دارد یک Session Ticket برای کاربر صادر می کند.

9. با توجه به Session Ticket کاربر می تواند با توجه به مجوز های دسترسی خود به Shared Folder دسترسی داشته باشد.

فرآیند فوق ممکن است پیچیده و زمان گیر به نظر آید اما تمام فرآیند در پشت صحنه صورت می گیرد و کاربر با این مسائل درگیر نمی شود. آنچه در اینجا به عنوان ارتباط Kerberos V5 و روابط Trust بحث شد ساده شده و مختصر شده است.

با تشکر از سایت پورت ۸۰ به آدرس http://www.erfantaheri.com

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

 

Trust های دستی

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

1. Shortcut Trust
2. External Trust
3. Realm Trust
4. Forest Trust

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

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

1. کنسول Active Directory Domains & Trusts را باز کنید.

2. روی دامینی که یک سمت از رابطه ی Trust است راست کلیک کنید و گزینه Properties را بزنید. توجه داشته باشید روی این دامین باید دارای privilege های ساخت یک رابطه trust باشید.

3. روی TAB (زبانه) Trust کلیک کنید و سپس روی دکمه new کلیک کنید. یک ویزارد برای ساخت یک رابطه Trust به شما کمک خواهد کرد.

4. در صفحه Trust Name، نام دامین دیگری که در رابطه Trust قرار می گیرد را وارد کنید و سپس next را بزنید.

5. اگر دامین وارد شده جزء همان جنگل (Forest) دامین جاری نباشد، باید یکی از سه نوع Trust زیر را انتخاب کنیدو:

- Forest
- External
- Realm

اگر در همان جنگل باشد، نوع Trust به صورت Shortcut در نظر گرفته می شود. در ادامه انواع Trust را مورد بررسی قرار می دهیم.

6. در صفحه Direction Of Trust باید جهت رابطه Trust را با توجه به شرح زیر معین کنید:

- Two-Way: یک ارتباط Trust دو طرفه که در آن هر دو دامین، دامین اعتماد شده و دامین اعتماد کننده خواهند بود. به عبارت مناسب تر؛ هر دو دامین تشخیص هویت یکدیگر را مورد اعتماد قرار می دهند.

- One-Way:Incoming : یک ارتباط Trust یک طرفه به صورتی که دامینی که روی آن کلیک راست کرده اید و Properties را زدید دامین اعتماد شده است و دامین دیگر دامین اعتماد کننده است. جهت فلش در دیاگرام به دامین اعتماد شده وارد می شود و استفاده از لغت Incoming به این منظور است.

- One-Way: Outgoing : یک ارتباط Trust یک طرفه به صورتی که دامینی که روی آن کلیک راست کرده اید و Properties را زدید دامین اعتماد کننده و دامین دیگر دامین اعتماد شونده است. جهت فلش در دیاگرام به دامین اعتماد شده وارد می شود از این رو لغت Outgoing انتخاب شده است.

7. در صفحه Sides of the trust با توجه به دسترسی های اکانت خود با توجه به توضیحات زیر یکی از گزینه های زیر را انتخاب کنید:

- Both this domian and specified domain : در هر دو سمت رابطه ی Trust نصب می شود. برای انتخاب این گزینه باید در هر دو سمت privilege های ساخت یک رابطه Trust را داشته باشید.

- This Domain Only : در دامینی که روی آن کلیک کرده اید و Properties را زده اید رابطه ساخته می شود و یک مدیر دیگر در دامین دیگر باید همین پروسه را روی آن دامین انجام دهد.

با توجه به گزینه های انتخابی قبلی مراحل بعدی متفاوت خواهند بود:

- اگر Both this domain and specified domain را انتخاب کرده اید، باید یک username و password با دسترسی های مناسب وارد کنید.

- اگر This Domain Only را انتخاب کرده اید، باید یک کلمه رمز که برای برقراری Trust استفاده می شود را انتخاب و وارد کنید. یک کلمه رمز نباید password خودتان باشید و باید یکتا باشد. پس از برقراری رابطه دامین آن را تغییر خواهد داد.

8. اگر Trust از نوع outgoing باشد؛ باید یکی از موارد زیر را انتخاب کنید:

- Selective Authentication

- Domain-Wide Authentication یا Forest-Wide Authentication با توجه به آنکه نوع Trust چیست External یا Forest

این گزینه ها در آینده توضیح داده می شود.

9. در پنجره جدید، توضیحات مختصر تنظیمات در نظر گرفته شما نمایش داده می شود. آن را بررسی کنید و Next را بزنید.

اگر در ساخت رابطه Trust گزینه both Sides را انتخاب کرده باشید، در اینجا مراحل پایان می پذیرد، اگر This Domain Only را انتخاب کرده باشید، رابطه Trust برقرار نمی شود مگر آنکه:

- اگر نوع رابطه ساخته شده توسط شما one-way:Outgoing است، یک مدیر شبکه در دامین دیگر، با توجه به فرآیند بالا یک رابطه Trust با نوع  One-Way:Incoming بسازد.

- اگر نوع رابطه ساخته شده توسط شما One-Way:Incoming است، یک مدیر شبکه در دامین دیگر، با توجه به فرآیند بالا یک رابطه Trust با نوع One-Way:Outcoming بسازد.

- اگر نوع رابطه ساخته شده توسط شما Two-way است، یک مدیر شبکه در دامین دیگر، با توجه به فرآیند بالا یک رابطه Trust با نوع Two-Way بسازد.

Trust های Shortcut

با توجه به آنچه که در خصوص Trust های درون دامینی و فرآیند طی شدن یک Trust به صورت Transitive گفته شد، این فرآیند به شدت می تواند Performance را کاهش دهد. همچنین اگر یکی از دامین کنترلر های مسیر Trust در دسترس نباشد به صورت کلی Authentication کاربر صورت نمی گیرد و دسترسی به سرویس مورد نظر صورت نمی گیرد. برای حل این مشکل از Shortcut Trust باید استفاده کنیم. لازم به ذکر است که Shortcut Trust ها لازم است در مرحله طراحی در نظر گرفته شوند تا از بروز مشکلات احتمالی جلوگیری گردد. Shortcut Trust ها Authentication و Session ها را در یک جنگل چند دامینی بهینه می کنند. دیاگرام زیر مثالی از دو Shortcut Trust است.

 

Trust های External

زمانی که لازم است با یک دامینی که در جنگل دیگری است کار کنیم، باید یک External Trust بسازیم. در دیاگرام زیر دو External Trust مشخص شده است.

در ادامه در مبحث امنیت روابط Trust درخصوص پیش بینی های امنیتی در این خصوص بحث خواهد شد.

Trust های Realm

زمانی که لازم است یک رابطه Trust بین یک دامین با سرویس های امنیتی روی پیاده سازی های دیگری از kerberos V5 انجام شود از Realm Trust استفاده می شود. مثلا در زمانی که لازم است دامین با یک Unix Kerberos V5 یک رابطه Trust برقرار کند. Realm Trust ها تنها به صورت One-Way امکان پذیر هستند بنابراین برای ایجاد یک رابطه دو طرفه، دو رابطه One-Way با جهت های متضاد ایجاد گردد.  همچنین به صورت پیش فرض این رابطه transitive نیست اما می توانند Transitive شوند.

اگر یک Kerberos v5 Realm غیر ویندوزی به دامین ویندوزی اعتماد کنند، در این صورت تمام اشیاء امنیتی در دامین ویندوزی مورد اعتماد قرار خواهند گرفت. اگر دامین ویندوزی به kerberos V5 Realm اعتماد کند کاربران در Realm می توانند به منابع دسترسی پیدا اما این فرآیند مستقیم نیست. زمانی که کاربر توسط یک Kerberos Realm غیر ویندوزی Authenticate می شود ticket صادر شده برای او شامل تمام مواردی که ویندوز جهت Authorization نیاز دارد نیست. بنابراین یک متد برای بازنشاندن اکانت ها لازم است. اشیاء امنیتی لازم در دامین ویندوزی ساخته می شود و به هویت های واقعی در Keberos Realm غیر ویندوزی مرتبط می گردند.

Trust های Forest

زمانی که لازم است بین دو کمپانی با دو جنگل متفاوت همکاری ایجاد شود از Forest Trust استفاده می شود. یک Forest Trust یک Trust به صورت One-way یا Two-Way است که به صورت Transitive بین دو Forest Root ایجاد می شود. Forst Trust ها به نسبت سایر Trust های دیگر، طرح ریزی و مدیریت ساده تری دارند از این رو در بسیاری از سناریو ها اولین گزینه ی انتخابی باید Forest Trust باشد. همچنین Forest Trust ها در بسیاری از سناریو ها همانند همکاری بین دو شرکت، ادغام شدن دو شرکت و مالکیت شرکت دیگر راهکار مناسبی است. همچنین در سازمان هایی با بیش از یک Forest – این عمل جهت ایزوله کردن سرویس و اطلاعات اکتیو دایرکتوری صورت می گیرد – گزینه مناسب ارتباط Forest Trust است.

زمانی که یک ارتباط Trust بین دو Forest ایجاد می شود SID Filtering (همچنین Domain quarantine گفته می شود) فعال می گردد. SID Filtering در ادامه مورد بحث قرار می گیرد. تصویر زیر یک مثال از Forest Trust است.

یک Forest Trust می تواند One-Way یا Two-Way باشد. همانطور که گفته شد Forest Trust دارای ویژگی تعدی است (Transitive است). با این وجود خودشان دارای این ویژگی نیستند. به عنوان مثال اگر tailspintoys.com به worldwideimporters.com اعتماد داشته باشد و worldwideimporters.com به northwindtrades.com اعتماد داشته باشد، tailspintoys.com به northwindtrades.com اعتماد ندارد. برای ایجاد این رابطه باید یک Trust دیگر ایجاد شود.

پیش نیاز ها

- برای ایجاد Forest Trust باید Functional Level در هر دو Forest ویندوز سرور 2003 باشد.

- همانطور که پیش تر گفته شد؛ برای ایجاد رابطه Trust باید دارای privilege های لازم باشید.

- برای ایجاد Forest Trust باید DNS به صورت مناسب تنظیم شده باشد:

1. اگر یک Root DNS Server وجود داشته باشد، می توان Root DNS Server را برای هر دو Namespace جنگل ها قرار داد و Root hints تمام DNS Server ها را به روز کرد.

2. اگر Root DNS Server وجود نداشته باشد، برای هر DNS Server می توان از conditional forwarders استفاده کرد.

3. اگر Root DNS Server وجود نداشته باشد و Forest DNS Namespace خانواده ویندوز سرور 2003 یا جدید تر نباشد، یک Secondary Zone در هر DNS namespace تنظیم می گردد.

نکته: در برقراری ارتباط بین یک دامین ویندوز سرور 2008 و دامین ویندوز NT 4.0 از External Trust استفاده می شود. به عنوان مثال اگر شما مدیر یک دامین ویندوز سرور 2008 هستید و کاربران می خواهند به منابعی که در دامین روی ویندوز NT 4.0 است دسترسی پیدا کنند باید یک رابطه Trust به صورتی که دامین ویندوز NT 4.0 به Windows Server 2008 اعتماد داشته باشد ایجاد کنید. در این حالت دامین ویندوز NT 4.0 دامین اعتماد کننده و دامین ویندوز سرور 2008 دامین اعتماد شده است.

مدیریت روابط

جهت اطمینان از کارکرد یک رابطه Trust، می توان این ارتباط را بین هر دو دامین ویندوزی Validate کرد. امکان Validate کردن Realm Trust وجود ندارد. برای این منظور:

1. کنسول Active Directory Domains and Trusts را باز کنید.

2. روی دامینی که شامل رابطه است کلیک راست کرده و Properties را بزنید. روی tab (زبانه) Trust کلیک کنید و سپس Trust که می خواهید Validate کنید را انتخاب کنید.

3. روی Trust مورد نظر کلیک راست کنید و Properties را بزنید. سپس Validate را بزنید. Yes را برای Validate کردن یک Incoming Trust بزنید. همچنین می توانید No را برای عدم Validate کردن بزنید.

4. با استفاده از دستور زیر همچنین می توانید یک رابطه را Validate کنید:

netdom trust TrustingDomainName /domain:TrustedDomainName /verify

5. برای حذف یک رابطه می توانید Remove را بزنید و یا از دستور زیر در خط فرمان استفاده کنید:

netdom trust TrustingDomainName /domain:TrustedDomainName /remove
[/force] /userD:User PasswordD:*

توجه: استفاده از سوییچ Force برای حذف Realm Trust ها لازم است.

با تشکر از سایت پورت ۸۰ به آدرس http://www.erfantaheri.com