پشتیبان گیری از Active Directory

جهت پشتیبان گیری از Active Directory ویندوز سرور مراحل ذیل را دنبال کنید :

1- از Run دستور NTBACKUP را اجرا کنید.

2- به حالت Advanced Mode رفته و روی لبه Backup کلیک کنید و از پنجره زیرین گزینه System State را انتخاب کنید.

( داخل System State پنج گزینه مشاهده می کنید که یکی از آنها Active Directory می باشد )

3- پشتیبان خود را در جای مناسبی تهیه نمایید.

active desktop policy in win server 2003

گاهی اوقات پیش می آید که می خواهیم در یک شبکه دومینی تصاویر زمینه تمام رایانه های متصل به دومین یا یک OU خاص را تغییر دهیم برای این کار مراحل ذیل را دنبال می کنیم :

ابتدا به Active Directory Users And Computers رفته و دومین یا OU مورد نظر را انتخاب می کنیم

کلیک راست - Properties و سپس تب Group Policy و سپس دکمه Edit

User Configuration  و بعد Administrative Templates و بعد Desktop و بعد Active Desktop

پارامتر Enable Active Desktop را به Enable تغییر می دهیم

پارامتر Active Desktop Wallpaper را به Enable تغییر داده و مسیر و نام عکس مورد نظر را مانند مثال در قسمت Wallpaper Name وارد کرده و طریقه نمایش عکس را در منوی باز شونده WallpaperStyle انتخاب می نماییم.

منبع : http://www.mrayaneh.ir/web/article82.html

seiz‌ كردن يك additional dc‌در windows server 2003

Master ها:(با تشكر از دوست عزيزم مهندس بهروز رئيسي)

در domain های مبتنی بر ویندوز سرور 2003 پنج Operation وجود دارند که تنها باید بوسیله یک سرور مدیریت و اجرا شوند. این Operation ها به قوانین Flexible Single Master Operations (FSMO) و یا Operations Master ها معروفند ، و در صورتی که توسط کاربر بر روی سرور دیگری به غیر از Root DC انتقال داده نشده باشند ، بصورت پیش فرض این Operation ها بوسیله Root DC مدیریت می شوند. این Operation ها عبارتند از:

·         Schema Master : DC ای است که همه تغییرات و update های schema در کل forest را بر عهده دارد.

·         Domain Naming Master : DC ای است که کنترل اضافه و یا کم کردن domain در کل forest را بر عهده دارد.

·         Infrastructure Master : DC ای است که مسئولیت update کلیه object های Domain اش که در Domain خودش و یا در Domain های دیگر استفاده می شوند، را بر عهده دارد.

·         Relative ID Master : DC ای است که مسئولیت پردازش RID هائی که توسط DC های دیگر در Domain درخواست می شوند را بر عهده دارد.

·         PDC Emulator : DC ای است که در Domain خود  را به عنوان Primary DC به Workstation ها ، Member Server ها و DC هائی که ویندوز Pre 2000 دارند ، معرفی می کند. از Primary DC به عنوان Domain Master Browser و در زمان تغییر Password ها استفاده می شود.

 

 Seizing:

در هنگام fail سروری که FSMO ها بر روی آن قرار دارند ، و یا در هنگام استفاده از Additional DC به عنوان DC اصلی این Operation  ها باید به سرور مذکور انتقال یابند. این عمل در اصطلاح به Seizing معروف است و با استفاده از Command و دستور Ntdsutil قابل انتقال هستند.

 

** تمامی موارد زیر باید بر روی سرور Failover صورت گیرد به عنوان مثال اگر سرورDC  اصلی را ITDC در نظر بگیریم در هنگام Seizing باید به سرور ITSD و یا همان سرور Additional مراجعه کنیم.

** دقت شود در هنگام Seizing مارکر GC (Global Catalog) سرور Additional برداشته شده باشد، در غیر این صورت در هنگام Seizing با پیغام خطا مواجه می شوید. برای چک کردن آن به Domain and Trust رفته در properties از روی نام سرور در tab اول به دنبال مارکر Global Catalog بگردید.

 

Seizing with Ntdsutil:

·         Command Prompt را باز کرده و دستور ntdsutil را وارد نمایید.

C:\WINDOWS>ntdsutil

ntdsutil:

 

·         سپس roles را تایپ کرده و enter کنید.

ntdsutil: roles

fsmo maintenance:

·         سپس connections را تایپ کرده و enter کنید.

fsmo maintenance: connections

server connections:

 

·         سپس connect to server را تایپ و enter کنید که servername نام سرور additional است.

server connections: connect to servername ITDS

Connected to ITDS using credentials of locally logged on user.

server connections:

 

·         سپس q را تایپ کرده و enter کنید.

server connections: q

fsmo maintenance:

·         دستورات زیر را به ترتیب تایپ کنید و enter کنید. بعد از enter از پیغام ظاهر شده بر روی yes کلیک کنید و سپس چند دقیقه تا اتمام عملیات صبر کنید.

Seize domain naming master

Seize infrastructure master

Seize PDC

Seize RID master

Seize schema master

 

** حتما در Forward Lookup Zone سرور چک شود که DNS به Primary تغییر ماهیت داده باشد.

Seizing in Additional Domain controller(DC) for Microsoft windows server

اين مطلب را دوست و همكار عزيز بهروز رئيسي تهيه و تدوين كرده است كه بدينوسيله از او سپاسگذاري و تشكر مي كنم.

Operations Master ها:در domain های مبتنی بر ویندوز سرور 2003 پنج Operation وجود دارند که تنها باید بوسیله یک سرور مدیریت و اجرا شوند. این Operation ها به قوانین Flexible Single Master Operations (FSMO) و یا Operations Master ها معروفند ، و در صورتی که توسط کاربر بر روی سرور دیگری به غیر از Root DC انتقال داده نشده باشند ، بصورت پیش فرض این Operation ها بوسیله Root DC مدیریت می شوند. این Operation ها عبارتند از:
•    Schema Master : DC ای است که همه تغییرات و update های schema در کل forest را بر عهده دارد.
•    Domain Naming Master : DC ای است که کنترل اضافه و یا کم کردن domain در کل forest را بر عهده دارد.
•    Infrastructure Master : DC ای است که مسئولیت update کلیه object های Domain اش که در Domain خودش و یا در Domain های دیگر استفاده می شوند، را بر عهده دارد.
•    Relative ID Master : DC ای است که مسئولیت پردازش RID هائی که توسط DC های دیگر در Domain درخواست می شوند را بر عهده دارد.
•    PDC Emulator : DC ای است که در Domain خود  را به عنوان Primary DC به Workstation ها ، Member Server ها و DC هائی که ویندوز Pre 2000 دارند ، معرفی می کند. از Primary DC به عنوان Domain Master Browser و در زمان تغییر Password ها استفاده می شود.

 Seizing:
در هنگام fail سروری که FSMO ها بر روی آن قراردارند ، و یا در هنگام استفاده از Additional DC به عنوان DC اصلی این Operation  ها باید به سرور مذکور انتقال یابند. این عمل در اصطلاح به Seizing معروف است و به دو صورت با استفاده از Command و یا GUI قابل انتقال هستند.  در حالت استفاده از Command از tools ای با نام Ntdsutil استفاده می گردد.
Seizing with GUI :
در این روش ابتدا قبل از استفاده از Snap-in های موجود Schmmgmt.dll باید بر روی سرور Failover رجیسترگردد.
1.    Register Schmmgmt.dll :
•    دستور  regsvr32 schmmgmt.dll را در Run تایپ نمایید و Enter کنید.
•    سپس بر روی OK پس از دریافت پیغام Successful کلیک کنید.
 *تمامی موارد زیر باید بر روی سرور Failover صورت گیرد و در صورتی که با استفاده از سرور دیگری قصد Seizing را دارید، باید نام و یا آدرس سرور مربوطه را در هنگام Connect شدن وارد نمایید. به عنوان مثال اگر سرورDC  اصلی را ITDC در نظر بگیریم در هنگام Seizing باید به سرور ITSD و یا همان سرور Additional مراجعه کنیم.


2.    Transfer the Schema Master Role :
•    در mmc ویندوز Active Directory Schema  را انتخاب نمایید.
•    در منوی باز شده بر روی Active Directory Schema راست کلیک کرده و Change Domain Controller را انتخاب نمایید.
•    در Specify Name کلیک کرده نام سرور جدید را وارد و OK را انتخاب نمایید.
•    در منوی باز شده بر روی Active Directory Schema راست کلیک کرده و Operation Master را انتخاب نمایید.
•    بر روی Change کلیک کنید.
•    سپس بر روی OK کلیک کنید تا عملیات انتقال صورت پذیرد و بر روی Close کلیک نمایید.


3.    Transfer the Domain Naming Master Role :
•    Active Directory Domain and Trust را باز نمایید.
•    در صورتی که برروی سروری که می خواهید role را به آن اختصاص دهید نیستید بر روی Active Directory Domain and Trust راست کلیک کرده و Connect to Domain Controller را انتخاب نمایید.
•    در هر صورت پس از انتخاب سرور مورد نظر بر رویActive Directory Domain and Trust  راست کیک کرده و Operation Master را انتخاب نمایید.
•    بر روی Change کلیک کنید.
•    سپس بر روی OK کلیک کنید تا عملیات انتقال صورت پذیرد و بر روی Close کلیک نمایید.


4.    Transfer the RID Master, PDC Emulator, and Infrastructure Master Roles :
•    Active Directory Users and Computers را باز کنید.
•    در صورتی که برروی سروری که می خواهید role را به آن اختصاص دهید نیستید بر روی Active Directory Users and Computers راست کلیک کرده و Connect to Domain Controller را انتخاب نمایید.
•    در هر صورت پس از انتخاب سرور مورد نظر بر رویActive Directory Domain and Trust  راست کیک کرده وارد All Tasks شده و Operation Master را انتخاب نمایید.
•    در tab های RID ، PDC و Infrastructure بر روی Change کلیک کنید.
•    سپس بر روی OK کلیک کنید تا عملیات انتقال صورت پذیرد و بر روی Close کلیک نمایید.

دستورات مهم در win2003 server

در ادامه مبحث دستورات و Commandهای موجود در ویندوز سرور 2003 به سراغ دستورات کاربردی دیگری می رویم که در ارتباط های راه دور یا Remote بسیار موثر و کاربردی می باشند.

دستور DSMod :

جهت تغییراتدر یک  User یا Group استفاده می شود. با دستور DSMod نمی توان اسم کروه را Rename کرد.

دستور DSGet :

زمانی که شما مثلا به دنبال شماره تلفن یکی از کاربران خود هستید و می خواهید آنرا از پروفایل کاربری او بدست آوری با استفاده از این دستور به صورت زیر بایستی عمل نمایید :

Dsget user cn=pouya,ou=webDepartment,dc=securenetwork,dc=local -hometel

و این دستور دارای سوئیچ های دیگری می باشد که می توانیم تمامی مشخصات یک User یا Group را بدست آوریم.

دستور DSMove :

جهت جابه جایی یک Object از جایی به جای دیگر استفاده می شود. بایستی به این نکته توجه شود که این دستور فقط در یک Domain کاربرد دارد.

Dsmove cn=pouya,ou=webDepartment,dc=securenetworks,dc=local -newparent ou=networkDepartment, dc=securenetworks,dc=local

* سوئیچ newparent مسیر جدید قرارگیری Object را مشخص می نماید.

* ما می توانیم سوئیچ newname را قبل از سوئیچ newparent برای اینکه این Object در محل جدید با نامی دیگر منتقل شود داشته باشیم.

دستور dsrm :

جهت پاک کردن یک Object در AD می توانیم از این دستور استفاده نماییم. در صورتی که می خواهیم تمامی زیرشاخه های مثلا یک OU هم پاک شوند باید از سوئیچ sub tree نیز استفاده نماییم.

دستور dsquery :

جهت پیدا کردن یک Object در AD از این دستور استفاده می شود.

dsquery user -name ali

در صورتی که بخواهیم از تمامی Userهای موجود در داخل AD در درون یک فایل txt پشتیبان داشته باشیم بایستی به صورت زیر با استفاده از دستور dsquery عمل نماییم :

dsquery user >d:\users.txt

دستور CSVDE :

جهت Import کردن یا Export کردن Object ها به AD و یا از AD این دستور به کار می رود. به این نکته باید توجه داشته باشیم که برای import کردن باید حتما از سوئیچ i استفاده نماییم و برای Export کردن نیازی به سوئیچی نمی باشد. مثالی از Export کردن Object ها :

CSVDE -f e:\log.txt

با سوئیچ f می توانیم نام و محل ذخیره فایل را مشخص نماییم.

دستور ldifde :

این دستور همانند دستور CSVDE عمل می کند و تنها تفوت آن در حالت فرمت خروجی و چیدمان Object ها در داخل فایل خروجی می باشد و از نظم بهتر و شفاف تری برخوردار است.

برای اطلاعات بیشتر در رابطه با دستورات به منابع زیر مراجعه نمایید:

http://technet.microsoft.com/en-us/library/cc732406.aspx

http://technet.microsoft.com/en-us/library/cc731094.aspx

http://technet.microsoft.com/en-us/library/cc732952.aspx

http://technet.microsoft.com/en-us/library/cc787549.aspx

http://support.microsoft.com/kb/237677

 

 

در ادامه مبحث جلسه گذشته از Course سرور 2003 به دستورات و Command های موجود در این ویندوز برای هر چه بهتر مدیریت کردن شبکه رسیدیم و به دستور Dsadd تا حدودی اشاره کردیم و در ادامه بیشتر به کارایی و قابلیتهای این دستور می پردازیم.

دستور Dsadd علاوه بر ایجاد یک User برای ایجاد Object های دیگر در( AD ( Active Directory هم کاربرد دارد.به طور مثال برای ایاد یک( OU ( Organisational Unit ز این دستور به شکل زیر استفاده می شود. اما قبل از اینکه طریقه نوشتن و Syntax دستور رو بگم باید بگم که OU اصلا چیست و به چه کاری می آید. Organisational Unit به معنای واحد سازمانی است و برای دسته بندی و مدیریت بهتر واحد های مختلف یک شرکت و همچنین کاربران موجود در آن واحدها کاربرد دارد و البته OU ها قابلیتهای دیگری هم دارند از جمله قابلیت پذیرفتن( GPO ( Group Policy Object , ...

مثالی از دستور Dsadd برای ایجاد یک OU :

dsadd ou ou=test,dc=securenetworks,dc=com

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

dsadd ou ou=test,ou=mytest,dc=securenetworks,dc=com

به طور مثال در دستور بالا یک OU به نام mytest در داخل OU دیگری که قبلا با نام test وجود داشته در داخل Domain به نام securenetworks.com ساخته می شود.

ساخت Group توسط دستور dsadd :

dsadd group cn=engineers,ou=test,dc=securenetworks,dc=com

دستور بالا یک Group در داخل OU موجود در Securenetworks.com می سازد. البته بایستی توجه داشته باشید که زمانی Group را می سازیم به صورت پیش فرض نوع گروه از نوع Security و محدوده آن Global می باشد( که در مورد انواع گروه ها و نوع محدوده آنها در جلسات قبلی صحبت شده است).

* در صورتی که بخواهید یک گروه از نوع Distribution بسازید بایستی به صورت زیر دستور را وارد نمایید:

dsadd group cn=engineers,ou=test,dc=securenetworks,dc=com -secgrp no -scope u

دستور بالا اعلام می کند که این گروه که می سازیم از نوع Security نیست ( secgrp no-) و Scope آن از نوع Universal است ( scope u-).

* سوئیچ دیگری که در این دستور کارایی دارد سوئیچ members- می باشد که توسط این سوئیچ می توانید کاربران این گروه را مشخص کنید و برای این کار بایستی برای هر یک اعضاء Distinguish name هر user را به طور جداگانه نوشته و بین DN های Userها فاصله دهیم.

منبعی برای مطالعه بیشتر این دستورات:

http://technet.microsoft.com/en-us/library/cc770883.aspx

http://technet.microsoft.com/en-us/library/cc754037.aspx

آیا می توانم یک دامین در ویندوز 2003 سرور را rename کنم؟

 

بله؛ شما با استفاده از ابزار Server 2003 Active Directory Domain Rename Tool می
توانید این کار را انجام دهید. این ابزار یک متدلوژی مناسب و ایمن برای rename کردن
یک یا چند دامین در یک درخت را فراهم می اورند . همچنین DNS name و یا NetBIOS هم
می تواند تغییر کند.

تذکر: این عمل در windows 2000 family امکان پذیر نیست.

توجه : دامین های Windows 2000 در صورتی که در Mixed mode باشند قابل Rename کردن هستند البته نه با این روش.

دامین های Windows Server 2003 پس از آنکه ساختار جنگل ( Forest ) آن ها
ساخته شد قابل rename کردن هستند. راه تعییر ساختار سلسه مراتبی یک درخت tree
موجود، تغییر نام شاخه های آن است. به عنوان مثال شما می توانید یک Child-Domain را
rename کنید تا یک Parent-Domain دیگری داشته باشد و یا می توانید یک Child-Domain
را rename کنید تا به یک Root-Domain تبدیل شود.

Rename کردن یک domain در windows server 2003 قابلیتی با شکل جدید است که ایجاد
شده و فقط به عنوان انجام مراحل rename کردن به صورت پشتیبانی شده و در مواقع ضروری
است. استفاده از این ابزار نباید به صورت یک روتین برای انجام عملیات مدیریتی تبدیل
شود. عملیات قدری پیچیده است و نباید با سرعت و عجله انجام شود.

محدودیت ها در بازسازی دامین ها درجنگل ویندوز 2000 :

بازسازی جنگل در ویندوز سرور 2003 قابلیت جدید است که برای حل مسائلی است که در
ویندوز 2000 آنها در نظر گرفته نشده بود. در ویندوز سرور 2000 واقعا قابلیت بازسازی
ساختار جنگل forest در نظر گرفته نشده بود و راه مناسب انجام این کار از نو ساختن
اجزاء بود. در ویندوز 2000 شما نمی توانید :

1) اسم DNS و یا NetBIOS دامین را تغییر دهید. با اینکه نمی توانید Rename کنید می
توانید با move کردن برخی از محتویات به دامین جدیدی در برخی سناریو ها مشکلات را
حل کنید . ابزار Active Directory Object Manager MoveTree در خانواده ویندوز سرور
2000 پشتیبانی می شود .

2) جا به جا کردن یک domain در یک جنگل تنها با یک عملیات . مشابه بالا می توانید
item ها را کپی کنید ولی نمی توانید تمام دامین در یک جنگل کپی کنید.

3) دو نیمه کردن ( Spilt ) یک دامین به دو دامین با یک عملیات . برای این کار باید
یک دامین جدید ایجاد کنید و سپس اجزاء را به دامین دوم move کنید.

4) یکی کردن دو دامین ( Merge ) . برای این کار باید تمام اجزاء و مولفه ها را باید
از یک دامین به دامین دیگر MOVE کنید و دامین خالی را decommission کنید.

بنابراین انجام عملیات مدیریتی در ویندوز سرور 2000 بیش از حد و به صورت دستی صورت
می گیرد.

در ویندوز سرور 2003 شما نمی توانید :

1) تغییر آنکه چه دامینی Forest-root است. البته امکان تغییر نام DNS و NetBIOS و
هر دو نام در خصوص Forest-root امکان پذیر است.

2) بیرون انداختن و یا افزودن یک دامین در یک Forest . تعداد دامین ها در زمان قبل
و بعد از ساخت یا بازسازی ساختار جنگل ثابت می ماند.

3) بازنامیدن ( rename ) یک دامین به نامی که به یک دامین با ساختار تک جنگلی
(single forest) در عملیات بازسازی داده شده است.

برای اطلاعات بیشتر و دانلود به Technet این صفحه مراجعه فرمایید.

 

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

 

Ntdsutil.exe از کجا می فهمد که وضعیت AD Restore mode هست؟

NTDSUTIL ابزاری است که در بسیاری از عملیات نگه داری پایگاه داده (DataBase) مربوط به AD استفاده می شود. مثل defragment پایگاه داده، Move کردن DB مربوط به AD و یا Log file ها و...


NTDSUTIL به شما اجازه می دهد تا بسیاری از اعمال را زمانی که AD ، UP است و در حال اجرا است را انجام دهید در حالی که برخی از اعمال باید در Restore mode انجام شود. زمانی که DC به صورت Restore mode بالا می آید، DC مقدار متغییر safeboot_option را disrepair می گذارد.


در زمانی که می خواهید به عملکرد های محافظت شده NTDSUTIL در زمانی که در restore mode نیستید دست یابید، با error زیر مواجه می شوید:

C:\WINDOWS>ntdsutil

ntdsutil: files

*** Error: Operation only allowed when booted in DS restore mode

"set SAFEBOOT_OPTION=DSREPAIR" to override - NOT RECOMMENDED!

ntdsutil:

با استفاده از دستور زیر می توانید کلک بزنید و این عمل را در خارج از restore mode انجام دهید.

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

set SAFEBOOT_OPTION=DSREPAIR

توجه : command فوق را در یک پنجره CMD دیگر بزنید ، نه پنجره ای که در آن ntdsutil اجرا می شود.

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

کنترل اندازه cache ، Internet Explorer توسط Group Policy

من این سوال را بارها و بارها در forum های مختلف دیدم و دیدم که بسیاری از مدیران شبکه ها در این خصوص توجه نکرده اند و باعث بروز مشکلات فراوانی شده اند. به همین جهت تصمیم گرفتم این مطلب تقریبا ساده را اینجا بنویسم.

در GPO هیچ گزینه ای برتنظیم اندازه Cache در IE وجود ندارد، بنابراین کاربران می توانند به راحتی ( اگر انداره Profile انها محدود نشده باشد) باعث پر شدن فضای دیسک شوند. این مطلب زمانی که کاربران مختلفی از یک کامپیوتر خاص در شیفت های مختلف اداری استفاده می کنند به یک مشکل بزرگ تبدیل می شود. و یا در Terminal Services مشکل بسیار جدی تر می شود.User profile ها به سرعت باعث پر شدن فضای دیسک روی سرور می شوند.همچنین در roaming profiles نیز همین مسئله به صورت مشابه موجود و مسائلی دیگر نیز ایجاد می کند.

توجه: مشابه سایر قالب های مدیریتی باید برخی از پیش زمینه ها را آماده کنید که در مقاله ای به نام افزودن یک قالب مدیریتی به به GPO توضیح داده شده است.اکنون در


User Configuration > Administrative Templates > Windows Components > Internet
Explorer Cache

می توانید اندازه cache را معین کنید.بدیهی است که فقط در سیستم عامل های بالای
2000 و در محیط اکتیو دایرکتوری کار می کند.

 

 

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

نصب Active Directory به صورت Unattended

در این مقاله قصد دارم تا توضیحی مختصر ارائه دهم که چگونه می توان یک Answer File برای نصب اتوماتیک
Active Directory Domain Service در ویندوز سرور 2008 ساخت. واقعا ساختن یک Answer File به این منظور به اندازه ای که همه می گویند دشوار نیست و حتی می تواند بدون نوشتن مستقیم صورت پذیرد. نصب با استفاده از یک Answer File، که متداولا بین مدیران شبکه نصب Unattended گفته می شود، نیاز حضور یک مدیر را برای نصب Active Directory و استفاده از ویزارد ( Wizard ) مربوطه ( DCPromo ) را حذف می کند. همچنین دانش این کار زمانی که از Core Edition استفاده می کنید بسیار دارای اهمیت است.

برای ساختن یک Answer File دو راه وجود دارد. راه اول ساختن آن فایل به صورت دستی و در واقع یک کپی پیست کردن ساده در یک فایل متنی است که در این مقاله بررسی می کنم. راه دیگر گذرندان ویزارد DCPromo است و در زمان اتمام ذخیره تنظیمات در یک فایل و کنسل کردن عملیات که درباره این روش هم اشاره ای خواهم کرد.

1) ساختن Answer File به صورت دستی:

در اینجا چند مثال کاربردی می زنم که می توانید به راحتی با تغییر دادن آن ها، تنظیمات دلخواه خود را اعمال کنید.

قسمت های در بخش "[DCINSTALL]" مربوط به نصب و یا حذف قرار می گیرد. به عنوان مثال من فقط در خصوص نصب مثالی ذکر می کنم. برای اطلاعات بیشتر می توانید به مقاله شماره ی KB 947034 در مایکروسافت مراجعه کنید.

[DCINSTALL]

InstallDNS=yes
NewDomain=forest
NewDomainDNSName=erfan.local
DomainNetBiosName=erfan
SiteName=Default-First-Site-Name
ReplicaOrNewDomain=domain
ForestLevel=3
DomainLevel=3
DatabasePath="%systemroot%\NTDS"
LogPath="%systemroot%\NTDS"
RebootOnCompletion=yes
SYSVOLPath="%systemroot%\SYSVOL"
SafeModeAdminPassword=P@ssw0rd1

- DomainLevel : این قسمت domain functional level را مشخص می کند. و زمانی که دامین جدیدی در جنگل موجود ساخته می شود بر اساس مقادیر زیر تعیین می شود:
0 برای Windows 2000 Server native mode
2 برای Windows Server 2003
3 برای Windows Server 2008

- ForestLevel : این قسمت forest functional level را مشخص می کند و زمانی که جنگل جدید ساخته می شود بر اساس مقادیر زیر تغیین می شود:
0 برای Windows 2000 Server
2 برای Windows Server 2003
3 برای Windows Server 2008

تذکر: زمانی که دامین جدیدی را در جنگل موجود می سازید نباید از این قسمت استفاده کنید. این قسمت جایگزین SetForestVersio در ویندوز سرور 2003 شده است.

RebootOnSuccess : مشخص کننده این است که در پایان سرور restart شود یا نه. به یاد داشته باشید که برای اعمال تغییرات restart الزامی است. مقادیر موجود عبارت اند از :
Yes No NoAndNoPromptEither

در خصوص child domain :

[DCINSTALL]

ParentDomainDNSName=erfan.local
UserName=administrator
UserDomain=erfan
Password=P@ssw0rd1
NewDomain=child
ChildName=test
SiteName=Default-First-Site-Name
DomainNetBiosName=test
ReplicaOrNewDomain=domain
DomainLevel=3
DatabasePath="%systemroot%\NTDS"
LogPath="%systemroot%\NTDS"
SYSVOLPath="%systemroot%\SYSVOL"
InstallDNS=yes
CreateDNSDelegation=yes
DNSDelegationUserName=administrator
DNSDelegationPassword= P@ssw0rd1
SafeModeAdminPassword=P@ssw0rd1
RebootOnCompletion=yes

- CreateDNSDelegation : این قسمت مشخص می کند که آیا یک DNS delegation برای یک دی ان اس سرور جدید ایجاد شود و یا نه. در خصوص AD DS–integrated DNS تنها کار می کند.

- DNSDelegationPassword : این قسمت مشخص کننده ی کلمه عبوری است که برای ساخت و یا حذف DNS delegation استفاده می شود. می توانید از * برای سوال کردن از کاربر استفاده کنید.

- DNSDelegationUserName : این قسمت مشخص کننده ی نام کاربری است که برای ساخت و یا حذف DNS delegation استفاده می شود. اگر مقداری برای این قسمت مشخص نشود، به صورت پیش فرض از اعتباری که برای نصب اکتیو دایرکتوری استفاده شده است، استفاده خواهد شد.

- SiteName : به صورت پیش فرض Default-First-Site-Name است و مشخص کننده ی site name است البته زمانی که جنگل جدید ساخته می شود.
برای ساختن درخت جدید در جنگل موجود:

[DCINSTALL]

UserName=administrator
UserDomain=erfan
Password=P@ssw0rd1
NewDomain=tree
NewDomainDNSName=otherlab.local
SiteName=Default-First-Site-Name
DomainNetBiosName=otherlab
ReplicaOrNewDomain=domain
DomainLevel=3
DatabasePath="%systemroot%\NTDS"
LogPath="%systemroot%\NTDS"
SYSVOLPath="%systemroot%\SYSVOL"
InstallDNS=yes
CreateDNSDelegation=yes
DNSDelegationUserName=administrator
DNSDelegationPassword= P@ssw0rd1
SafeModeAdminPassword=P@ssw0rd1
RebootOnCompletion=yes

در خصوص additional domain controller :

[DCINSTALL]

UserName=administrator
UserDomain=erfan
Password=P@ssw0rd1
SiteName=Default-First-Site-Name
ReplicaOrNewDomain=replica
DatabasePath="%systemroot%\NTDS"
LogPath="%systemroot%\NTDS"
SYSVOLPath="%systemroot%\SYSVOL"
InstallDNS=yes
ConfirmGC=yes
SafeModeAdminPassword=P@ssw0rd1
RebootOnCompletion=yes

در خصوص دامین کنترلر اضافی که از متد ( Install From Media ( IFM استفاده
می کند:

[DCINSTALL]

UserName=administrator
UserDomain=erfan
Password=P@ssw0rd1
DatabasePath="%systemroot%\NTDS"
LogPath="%systemroot%\NTDS"
SYSVOLPath="%systemroot%\SYSVOL"
SafeModeAdminPassword=P@ssw0rd1
CriticalReplicationOnly=no
SiteName=Default-First-Site-Name
ReplicaOrNewDomain=replica
ReplicaDomainDNSName=erfan.local
ReplicationSourceDC=dc1.erfan.local
ReplicateFromMedia=yes
ReplicationSourcePath=
RebootOnCompletion=yes

- ReplicateFromMedia : مشخص کننده ی فرایند برداشتن اطلاعات اکتیودایرکتوری در متد IFM است.

- ReplicationSourcePath : مشخص کننده محلی است که فایل های IFM در آن قرار دارند.

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

[DCINSTALL]

UserName=administrator
UserDomain=petrilab
Password=P@ssw0rd1
PasswordReplicationDenied=
PasswordReplicationAllowed =
DelegatedAdmin=
SiteName=Default-First-Site-Name
CreateDNSDelegation=no
CriticalReplicationOnly=yes
ReplicaOrNewDomain=ReadOnlyReplica
ReplicaDomainDNSName=petrilab.local
DatabasePath="%systemroot%\NTDS"
LogPath="%systemroot%\NTDS"
SYSVOLPath="%systemroot%\SYSVOL"
InstallDNS=yes
ConfirmGC=yes
RebootOnCompletion=yes

2) استفاده از ویزارد DCPromo :

روی یک سرور دیگر ویزارد DCPromo را با استفاده از تایپ دستور DCPromo و روش عادی نصب اکتیودایرکتوری پیش بگیرید و در پایان تنظیمات را در یک فایل ذخیره نمایید. ( این ویژگی جدید در ویندوز سرور 2008 است) و با زدن دکمه یExport Settings یک فایل در %systemdrive% ایجاد می شود.


برای استفاده از فایل پاسخ answer file ای که ساخته اید از دستور زیر و سوییچ /unattend استفاده کنید:

dcpromo /unattend:

توجه : این ویزارد بدون چک کردن موارد مورد نیاز به شما اجاره نمی دهد که از یک صفحه ی ویزارد به صفحه بعدی بروید. پس از یک دامین کنترولر نمی توانید برای ساخت Answer File استفاده کنید.
همچنین نمی توانید از این ویزارد برای ساخت replica نمی توانید استفاده کنید اگر نسخه اصلی هنوز ساخته نشده. در ضمن در هر صورت دانستن اطلاعات روش اول را به شما توصیه می کنم

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

پیش بینی نیاز های سخت افزای برای نصب Active Directory

برای یک Active Directory برنامه ریزی
شده چگونه می توانم پیش بینی کنم که چقدر حافظه احتیاج است؟

ابزار Active Directory service Sizer به شما این امکان را می دهد تا تقریبا پیش بینی کنید که چه امکانات سخت افزاری برای راه اندازی Active Directory مورد نیاز است.
بر اساس اطلاعات ورودی کاربر و فرمول های از پیش تعیین شده این ابزار می تواند معین کند:

1) تعداد DC های لازم در هر سایت و در هر دامین
2) Global Catalog Servers در هر سایت و درهر دامین
3) CPU های هر ماشین و نوع ان ها
4) دیسک های مورد نیاز جهت ذخیره سازی AD

همچنین موارد زیر را به صورت تخمینی پیش بینی می کند:

1) مقدار memory مورد نیاز
2) پهنای باند بهینه
3) سایز پایگاه داده ( Domain Database )
4) سایز Global Catalog
5) پهنای باند لازم جهت replication بین سایت ها

لیست اطلاعاتی که لازم است به صورت تخمینی در هر دامینی پیش از ایجاد در نظر گرفته شود:

1) تعداد کل کاربران – بیشترین تعداد کاربران هم زمان ( هم زمانی از لحاظ بازی کاری)
2) تعداد کل attributes ها برای هر user
3) میانگین تعداد گروه هایی که هر کاربر در آن عضو خواهد بود. تعداد گروه هایی که یک کاربر در آن عضو است در زمان تقریبی ورود به سیستم ( Logon ) بسیار موثر است
4) نرخ بیشینه ورود به سیستم در هر ثانیه. چه interactive چه network و چه Batch .
5) نرخ منقضی شدن کلمه های عبور در روز ( Password )
6) تعداد کلاینت های قدیمی در شبکه
7) تعداد کلاینت های جدید در شبکه
8) مقدار استفاده دلخواه از CPU در هر DC
9) نوع CPU که ارجح است
10) حجم کاری مدیران شبکه
11) Microsoft Exchange 2000 یا عدم Microsoft Exchange 2000
12) مسائل مربوط به DNS ! ایا از Active Directory-integrated DNS zones استفاده می شود؟ تعداد ارتباطات dial-inدر هر روز که ممکن است عضو دامین شوند و زمان DHCP leases چقدر است؟ و...
13) مسائل مربوط به سایر نرم افزارهایی که با Active Directory سروکار دارند. تغییراتی که با Active Directory Connector (ADC) و یا سایر نرم افزار های synchronization مربوط به Active Directory اعمال می شوند مثلMicrosoft Directory Synchronization Services باید تعداد عملیاتشان در هر ثانیه تخمین زده شود.

تذکر : همواره تلاش کنید که از آخرین ورژن این ابزار استفاده کنید.

حوزه عملکرد دامین ها در ویندوز سرور 2008

Windows Server 2008 Active Directory Domain Functional Levels

در ویندوز 2003 سطوح عملکرد (Functional Level) بر اساس نظریه mixed/native که با ویندوز 2000 مطرح شده بود می باشد. در ویندوز سرور 2008 ویژگی های جدید و مزایایی مهم را در این خصوص شاهد هستیم.

به صورت پیش فرض زمان نصب سرویس اکتیو دایرکتوری دامین ( AD DS ) در این دامین و یا جنگل جدید، حوزه عملکرد در پایین ترین سطح یعنی "Windows 2000 Native Mode" خواهد بود. این مسئله به علت سازگاری با نسخ قدیمی ویندوز سرور که همچنان در شبکه ها در حال کارکردن هستند می باشند. اما چنانچه حوزه عملکرد را افزایش دهید، به وِیژگی های بسیار جالبی دست پیدا خواهید کرد. توجه داشته باشید که با افزایش سطح عملکرد، بدیهی است تمام دامین کنترلر ها (Domain Controllers) موجودی که از سیستم عامل های قدیمی تر (ویندوز سرور 2003) استفاده می کنند، نمی توانند به دامین اضافه شوند.

البته تعداد شبکه هایی که می شود در آن NT 4.0 BDCs را یافت بسیار کم است اما  به یاد داشته باشید که در ویندوز سرور 2008 هیچ پشتیبانی از NT 4.0 BDCs به عمل نمی آید. به صورت کلی دیگر دلیلی برای استفاده از Mixed Mode وجود نخواهد داشت. اگر همچنان در شبکه ای که مدیر آن هستید NT 4.0 BDCs پیدا می شود، با یک برنامه ریزی سریع، به روز رسانی کنید.اگر از حوزه عملکرد Windows 2000 Native Mode استفاده می کنید، ویندوز سرور 2008 تنها از سرویس پک چهارم ویندوز 2000 پشتیبانی می کند. هرچند به شما توصیه می کنم تا برای رفع مشکلات چنانچه مشکلات مالی کلانی رو به رو نیستید، به روز رسانی کنید. البته اگر در شبکه شما دامین کنترلر Windows server 2000 وجود ندارد، با مشکلی رو به رو نخواهید بود و می توانید سطوح عملکرد را افزایش دهید.

توجه : کلاینت ها بدون توجه به نوعشان می تواند در هر حوزه عملکردی در دامین و یا جنگل به منابع شبکه دسترسی پیدا کنند. سطوح عملکرد تنها مربوط به تعاملات دامین کنترلر ها با یکدیگر می شود و ربطی به کلاینت ها ندارد. البته به خاطر داشته باشید که بدون توجه به حوزه کارکرد، ویندوز ان تی سرور 4.0 (Windows NT Server 4.0) توسط ویندوز سرور 2008 (Windows Server 2008)  پشتیبانی نمی شود.

حوزه های کارکرد دامین :

الف) Windows 2000 Native Mode :
دامین کنترلر های مورد پشتیبانی : Windows Server 2000 ، 2003 ، 2008

مزایا:
1)Group nesting : بر خلاف ویندوز NT 4.0 ، می توان یک گروه عضو گروه دیگری باشد. توجه داشته باشید در همان Scope باید باشد.
2) امکان استفاده از نوع گروه Universal security groups
3)SidHistory : امکان استفاده از SidHistory در زمان انتقال یک object بین دو دامین
4) امکان تبدیل یک گروه security به یک گروه distribution

ب) Windows Server 2003 Mode :
دامین کنترلر های Windows Server 2003 و 2008

مزایا:
1)Universal group caching : جهت حذف نیاز وجود global catalog server به صورت local .
2)نامیدن مجدد دامین کنترلرها "Domain Controller rename "
3)Logon time stamp update
4) بهبود های Multivalued attribute replication : امکان داشتن بیش از 5000 عضو در یک گروه و replication  بهتر
5)Lingering objects (zombies) detection
6)AD-integrated DNS zones در application partitions : امکان ذخیره سازی اطلاعات DNS در همان پارتیشن اکتیودایرکتوری در زمان replication و... بسیار مفید خواهد بود.

 و بسیاری موارد دیگر که احتمالا ازحوصله خوانندگان این مقاله خارج است.

ج)Windows Server 2008 Mode :
دامین کنترلرهای Windows Server 2008

توجه : افزایش حوزه عملکرد به ویندوز سرور 2008 غیر قابل بازگشت خواهد بود. تمامی دامین کنترلر های موجود به غیر از ویندوز های سرور 2008 دیگر نمی توانند عمل کنند و در حقیقت ویزارد "wizard" در این صورت به شما اجازه افزایش حوزه عملکرد را نخواهد داد. پیش از این ارتقا توجه کنید که تمام نسخ ویندوز دامین کنترلر ها را به ویندوز سرور 2008 به روز رسانی کرده باشید.

مزایا:
1)Fine-grained password policies : امکان اعمال سیاست های کلمه عبور چندگانه برای کاربران یک دامین
2)Read-Only Domain Controllers  : امکان پیاده سازی دامین کنترلر هایی که یک نسخه فقط خواندنی از پایگاه داده NTDS هستند.
3)سیستم های رمزنگاری پیشرفته : AES 128 و 256 برای پروتکل Kerberos .
4)Granular auditing : داشتن یک history مخصوص object  در اکتیو دایرکتوری "Active Directory"
5)Distributed File System Replication -DFSR: امکان SYSVOL برای استفاده از DFSR در replication که مزایای بسیاری را خود ایجاد می کند.
6) اطلاعات مربوط به آخرین logon به صورت Interactive  که سبب می شود و تعداد تلاش برای logon  های ناموفق.

و بسیاری موارد دیگر که احتمالا ازحوصله خوانندگان این مقاله خارج است.

توجه فرمایید که این مطلب در خصوص حوزه عملکرد دامین ها (Domain Function Levels) می باشد و در خصوص حوزه عملکرد جنگل ها (Forest function levels) قدری متفاوت است.
در آینده در خصوص چگونگی ارتقا به حوزه عملکرد ویندوز سرور 2008 بحث خواهد شد و در اینجا فقط کلیات را پیش از انجام این عمل بیان کردیم.

 

 

پیش نیاز های نصب اکتیو دایرکتوری

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

  در این مقاله قصد دارم تا پیش نیاز های لازم برای نصب این سرویس مهم در ویندوز 2008 را مورد بررسی قرار بدهم، در مقالات بعدی در خصوص نصب این سرویس بسیار صحبت خواهد شد.

 همچنین توصیه می کنم مقاله نیاز های سخت افزاری نصب اکتیو دایرکتوری برای یک دامین برنامه ریزی شده

بخوانید.

  
  ابتدا نگاهی سریع به آنچه باید آماده کنیم را ذکر می کنم:

1) حداقل یک پارتیشن NTFS با فضای خالی مناسب

2) یک اشتراک کاربری مدیر (نام کاربری و کلمه عبور) در ویندوز سرور 2008

3) کارت شبکه متصل به شبکه (به یک سوییچ، هاب hub و یا یک کامپیوتر دیگر) و IP ثابت

4) یک DNS Server که می تواند و در برخی موارد توصیه می شود با خود نصب DC و DCpromo نصب شود.

5) دور اندیشی و برنامه ریزی و...

1) حداقل یک پارتیشن NTFS با فضای خالی مناسب:

 شاید گفتن این مطلب دیگر الزامی نباشد چرا که دیگر اغلب از فایل سیستم NTFS استفاده می شود، اما بر حسب عادت از گذشته و احتمال وجود چنین مسئله این را متذکر می شوم. فلدر SYSVOL باید در یک پارتیشن با فایل سیستم NTFS قرار گیرد. به صورت معمول در %systemdrive% که اغلب C هست قرار می گیرد. حال انکه بسیار بهتر است در یک پارتیشن دیگر قرار گیرد. چنانچه یک پارتیشن NTFS ندارید، از دستور زیر برای تبدیل یکی از پارتیشن ها به NTFS استفاده کنید.
توصیه: فایل سیستم NTFS از سایر فایل سیستم ها بسیار کارا تر است، اگر محدودیتی ندارید حتما از NTFS استفاده کنید.

convert c:/fs:ntfs

 معمولا به 250 مگابایت (250MB) فضای خالی روی پارتیشنی که روی آن فایل های اکتیودایرکتوری قرار می گیرند نیاز است. توجه داشته باشید که این فضا زمانی که از Object ها، Users و Group های بسیاری استفاده کنید بیشتر نیاز است. ضمن انکه در آینده خواهید دید، اکیدا توصیه می شود در صورت امکان برخی فایل ها را روی دو هارد دیسک ذخیره کنید.

2) یک اشتراک کاربری مدیر (نام کاربری و کلمه عبور) در ویندوز سرور 2008 :

 به یاد داشته باشید که فقط local Administrators می توانند اولین دامین را در یک جنگل جدید ایجاد کنند و سایر سناریوها مثل Additional Domain Controller (دامین کنترلر اضافی) به Domain Admins و در سناریوی دامین جدید در درخت موجود به Enterprise Admins نیاز است.
همچنین به ورژن مناسب ویندوز توجه کنید، در اینجا ورژن های Standard ، Enterprise  یا Data Center کارا خواهند بود. در خصوص نصب اکتیودایرکتوری در Windows Server 2008 Core با توجه به عدم دسترسی به هیچ GUI در این حالب قدری متفاوت است و در آینده بیشتر در خصوص آن صحبت می کنیم. البته مقاله "نصب اکتیودارکتوری به صورت غیر حضوری Unattended " می تواند قدری به شما در این مورد کمک کند.

3) کارت شبکه متصل به شبکه (به یک سوییچ، هاب hub و یا یک کامپیوتر دیگر) و IP ثابت :

 سرور ضمن داشتن حداقل یک اتصال به حداقل یک شبکه ، باید دارای IP Address به صورت Static هم باشد. برای این منظور چنانچه یک DHCP Server در شبکه دارید، ابتدا حدودیی (Scope) که DHCP Server در آن IP اختصاص می دهد را بررسی کنید و سپس با یافتن یک IP که معمولا در زمان تنطیمات DHCP Server ، برای رشد شبکه و اختصاص به سرور ها رزرو می شود، این آدرس را به صورت دستی به سرور اختصاص دهید. در ضمن چنانچه در DHCP Sever در شبکه استفاده نمی شود ( که عجیب است!!!) به صورت دستی IP ها را در یک Subnet مناسب قرار دهید. معمولا از کلاس C برای اختصاص IP در شبکه های کوچک استفاده می شود. همچنین اگر با IP آشنایی ندارید مقاله "آشنایی اولیه با IP" را بخوانید. چنانچه در زمان نصب اکتیودایرکتوری این شرایط را فراهم نیاورید با پیغام زیر مواجه خواهید شد.

4) یک DNS Server که می تواند و در برخی موارد توصیه می شود با خود نصب DC و DCpromo نصب شود :

 من در خصوص نصب DNS Server در زمان نصب اکتیودایرکتوری (Active Directory) در ویندوز 2003 سرور توصیه کرده بودم که " به صورت دستی و پیش از نصب Active Directory این کار را انجام دهید. اما در ویندوز سرور 2008 به شما توصیه می کنم، چنانچه اولین دامین در یک درخت جدید را ایجاد می کنید، اجازه دهید تا این کار خودکار انجام شود.

اسامی یک قسمتی در DNS Name مشکل ساز خواهند شد:

 مایکروسافت اکیدا توصیه می کند تا از اسامی یک قسمتی مثل ( com، Net،Example،ErfanTaheri) استفاده نکنید. همچنین به شما توصیه می کنم که از پسوند local برای تاکید جدایی از وب سایت شرکتتان روی اینترنت استفاده کنید. این مسئله خود باعث جلوگیری از برخی مشکلات( هرچند مشکلات ابتدایی هستند) می شود. مثلا از ErfanTaheri.local و یا Example.local استفاده کنید. البته بسیاری واژه local را در انتهای اسم دامینشان نمی پسندند.

5) دور اندیشی و برنامه ریزی :

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

 

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

نصب اکتیو دایرکتوری در ویندوز سرور 2008

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

فاز اول:

1) ابتدا Server Manager را باز کنید. در منوی شروع "Start" آن را به راحتی می توانید ببینید، ضمن آنکه به صورت پیش فرض هر زمان که Login کنید بار می شود.

2)قسمت Roles را از ساختار درختی سمت چپ انتخاب کنید و سپس در سمت راست Add Roles را بزنید. تصویر یک

3) سپس Add Role Wizard باز خواهد شد. در این مرحله ویزارد از شما تقاضا می کند تا: تصویر دو
الف) آخرین به روز رسانی ها را دریافت کنید.
ب)از کلمه عبور قدرتمند استفاده کنید
ج)تنظیمات شبکه ای را کامل انجام دهید. همانند اختصاص IP به صورت ثابت "Static"

4)موارد فوق را رعایت کنید و سپس Next را بزنید. در قسمت بعد، لیستی از نقش هایی (Role) که ویندوز سرور 2008 می تواند در شبکه داشته باشد را به شما نمایش می دهد. در این قسمت Active Directory Domain Services را انتخاب کنید. (به اختصار AD DS گفته می شود. تصویر سه

5)با زدن Next ویزارد نصب اکتیودایرکتوری در موارد زیر هشدار می دهد: تصویر چهار
الف) برای redundancy حداقل دو دامین کنترلر در شبکه ایجاد کنید. به منظور عدم قطع سرویس دهی به کلاینت ها متداول است که از حداقل دو دامین کنترلر استفاده شود که در این خصوص در آینده صحبت می کنیم.
ب)AD DS نیاز به سرویس DNS در شبکه دارد. چنانچه قبلا نصب نشده، آن را نصب کنید. در این خصوص در مطلب پیش نیاز ها ذکر کردم که چنانچه اولین دامین در اولین جنگل را ایجاد می کنید اجازه دهید خودکار انجام شود. شما در این مرحله به راحتی این پیغام را در نظر نگیرید. ( موقتا )
ج) پس از پایان این ویزارد باید DCPromo.exe را اجرا کنید. در غیر این صورت اکتیودایرکتوری نصب نخواهد شد. در ویندوز سرور 2003 این عمل اتوماتیک صورت می گرفت.
د)نصب اکتیودایرکتوری سبب نصب DFS Namespaces ، DFS Replication و Filer Replication services نیز می شود. که خوب این دیگه از این بهتر نمی شود.

6)برای ادامه Next را بزنید و سپس با زدن Install عملیات نصب را تایید کنید. تصویر پنج

7)با مشاهده Installation Succeeded مطابق تصویر شش ، فاز اول عملیات نصب تمام شده.

فاز دوم:

8) می توانید روی لینک که در تصویر شش مشاهده می کنید کلیک کنید تا DCPromo.exe باز شود و یا در RUN وارد کنید. و یا هر روش دیگری که می پسندید. در اینجا با باز کردن Start Menu و Search به صورت سریعی DCPromo را باز کردم. تصویر هشت

9)در اینجا من Advanced Mode Installation را انتخاب می کنم. توصیه می کنم شما هم این عمل را انجام دهید. تصویر نه

10)Next را بزنید. در مرحله بعد تذکراتی در خصوص سازگاری با سیستم عامل های قبلی داده می شود که کم و بیش در مطلب پیش نیاز و حوزه عملکرد در موردش بحث شد. برای اطلاعات بیشتر به وب سایت مایکروسافت اینجا مراجعه کنید. اما به صورت کلی بدانید از ویندوز NT در ویندوز سرور 2008 به هیچ عنوان پشتیبانی نمی شود. پس چنانچه از این نسخه از ویندوز در شبکه خود هنوز استفاده می کنید، از ادامه مراحل خودداری کنید. تصویر ده

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

12)در مرحله بعدی باید نام Forest Root Domain را وارد کنید. به مواردی که در مقاله پیش نیاز تذکر داده شد توجه کنید. در اینجا از نام ADExample.com استفاده می کنم. تصویر دوازده

13) در این مرحله با زدن Next ویزارد چک می کند تا این نام قبلا در شبکه موجود نباشد. چنانچه موجود نباشد، پس از چند ثانیه نام NetBIOS از شما پرسیده خواهد شد که به صورت پیش فرض بخش اول نامی است که در بالا انتخاب کرده اید. توصیه می کن این نام را تغییر ندهید. تصویر سیزده

14)با زدن Next در مرحله بعد باید Domain Functional Level را انتخاب کنید که در مقاله ای جداگانه توضیح داده شده است. تصویر چهارده.

15)در مرحله بعدی باید تنظیمات اضافی را اعمال نمود. به صورت پیش فرض DNS Server انتخاب شده است. چنانچه اولین دامین کنترلر نباشد شما می توانید تنظیمات Global Catalog و Read-only Domain Controller را اعمال کنید. اما از آنجایی که در اینجا در حال نصب اولین دامین کنترلر هستیم، این موارد غیر قابل تغییر اند. تصویر پانزده

16)در صورت انتخاب DNS Server در این مرحله پیام هشداری دریافت می کنید مبتنی بر اینکه Parent Zone قابل دسترسی نیست. از آنجایی که در حال نصب اولین دامین در جنگل جدید هسیتم، با زدن Yes پیغام را تایید می کنیم. تصویر شانزده

17)سپس با توجه به آنچه در "پیش نیاز" صحبت شد، جای فلدر های ذخیره سازی اطلاعات را معین می کنیم. تصویر هفده

18) در این مرحله باید کلمه عبوری برای Directory Services Restore Mode انتخاب کنید. توصیه می شود این کلمه عبور با کلمه عبور خودتان متمایز باشد و به یادآوری آن ساده باشد. البته راهی برای تعویض این کلمه عبور وجود است که در آینده آن را ذکر خواهیم کرد. تصویر هجده

19)در مرحله بعدخلاصه ای از تنظیمات مشخص شده را می توانید مشاهده کنید. آن ها را بازبینی کنید تا مشکلی موجود نباشد. نکته جدید دیگری همانطوری که تصویر نوزده مشاهده می کنید وجود دارد دکمه Export settings  است. همانطوری که درنصب به روش Unattended توضیح داده شد ، با این گزینه می توانید یک answer file برای نصب اکتیو دایرکتوری های دیگری با همین تنظیمات استفاده کنید.

20)با زدن Next انجام نصب را تایید می کنید. این مراحل قدری طول می کشد و پس از پایان نیاز است تا کامپیوتر ریستارت "Restart" شود. یکی از کمک های مایکروسافت به شما مدیر شبکه گزینه Reboot on completion  است. به راحتی این گزینه را چک بزنید و به دقایقی را تا شروع مجدد فعالیت سرور و شروع داستان های پس از نصب اکتیو دایرکتوری یک چای یا قهوه میل کنید. در ضمن توجه داشته باشید که چنانچه این سرور شما سرویس های دیگری را به شبکه ارائه می دهد، باید در زمان بندی معین و اعلام قبلی به کاربران سرور را ریستارت کنید. تصویر بیست

توصیه می کنم در پایان تنظیمات و تغییرات اعمال شده را بررسی کنید. به عنوان مثال تنظیمات DNS و... را بازبینی کنید.

 

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

ویژگی های جدید اکتیو دایرکتوری در ویندوز سرور 2008

زمانی که سرویس اکتیو دایرکتوری "Active Directory" با ارائه ویندوز 2000 معرفی شد، یه سرعت یکی از پر کاربرد ترین سرویس ها در شبکه ها شد.  اکتیو دایرکتوری توسعه های بسیار زیادی را از ویندوز 2000 تا کنون پشت سر گذاشته و امروزه حتی شرکت های کوچک با توجه به هزینه های بسیار استفاده از اکتیو دایرکتوری ترجیح می دهند که از این سرویس استفاده کنند.

با انتشار اکتیو دایرکتوری ویندوز سرور 2003 مایکروسافت امکان یکپارچگی با سایر سرویس ها در شبکه را ایجاد کرد و در واقع به نحوی (هر چند ابتدایی) تمام سرویس ها در کنار یک دیگر کار می کردند. همچنین سرویس های Active Directory Federation Services به اختصار ADFS و Active Directory Applications Mode به اختصار ADAM و بسیاری موارد دیگر معرفی شدند که رشد بسیار چشمگیری برای اکتیو دایرکتوری "Active Directory" محسوب می شود.

اما در ویندوز سرور 2008 :

در ویندوز سرور 2008 ادامه یکپارچگی با سایر سرویس ها را می توان مشاهده کرد. ضمن آنکه Roleمتعددی که مربوط به اکتیو دایرکتوری می شود را می توان دید. در اینجا قصد داریم این Role "نقش ها" را مورد بررسی قرار دهیم.

الف) Active Directory Domain Services - AD DS :
AD DS نام جدید Active Directory Services است که مشابه قبل سرویس های ابتدایی Active Directory را شامل می شود. در این خصوص چهار مورد بهبود چشمگیر وجود دارد.

1)Read-only domain controllers - RODC : باعث ایجاد یک امنیت قدرتمند و قابل اطمینان در یک محیط نا امن می شود. یک دامین کنترلر فقط خواندنی باید از روی یک دامین کنترلر نوشتنی replicate شود. بدیهی است که در RODC تغییرات نمی تواند اعمال شود و در واقع می توان چنین تصور کرد که user credentials در آن ها ذخیره می شوند.

2)توسعه Auditing " بازبینی " : با دسته بندی وقایع "Event" در چهار دسته مختلف امکان بازبینی بسیار راحت تر شده. این دسته ها عبارت اند از : Directory Service Access ، Directory Service Changes ، Directory Service Replication و Detailed Directory Service Replication .

3) Granular password and account lockout policies : دامین ها دیگر محدود به یک سیاست کلمه عبور و تحریم کاربر نیستند. می توان برای هر گروهی یا کاربری سیاست خاص اعمال کرد.

4) Restartable AD DS : عملیات نگه داری را می توانید بسیار راحت تر انجام دهید. در گذشته لازم بود تا سرور را ریستارت کنید و در  Directory Services Restore Mode بوت کنید. اما اکنون به راحتی می توانید سرویس را Stop که باعث کاهش Downtime می شود.

ب) Active Directory Certificate Services - AD CS :
فکر می کنم هر چقدر از مزایایی این مورد بگویم باز هم کم گفتم. من فقط پنج مزیت چشمگیر را ذکر می کنم:

1) بهبود های Certificate Web enrollment support : استفاده از ActiveX control برای Web enrollment جایگزین کنترلر COM شده است. به عبارت دیگر XEnroll.dll جایگزین CertEnroll.dll شده است که باعص مدیریت آسان تر و امنیت فراتر می شود.

2) Network device enrollment support

3)Online certificate status protocol (OCSP) support  : که OCSP ابتدا وضعیت revocation تصدیق نامه را چک می کند.

4) Enterprise PKI - PKIView :  این ابزار جدید بیشتر نام جدیدی برای PKI Health است با این تفاوت که می تواند در MMC به صورت snap-in استفاده شود. برای مانیتور کردن Certificate Authority کاربرد دارد.

5) CAPI2 Diagnostics

ج) Active Directory Lightweight Directory Services - AD LDS :

AD LDS تغییر نام یافته ADAM است. در واقع AD LDS یک ورژن کوچک شده AD DS است که برای کاربرد Active Directory در برخی نرم افزار ها ساخته شده. بسیاری از نرم افزار های Customer Relationship Management که به اختصار CRM گفته می شود از Active Directory برای ذخیره سازی برخی موارد همانند کاربری ها استفاده می کنند. با AD LDS می توان بدون تغییراتی در مدیریت شبکه امکان کار با این نوع نرم افزار ها را ایجاد کرد.در این خصوص در آینده بسیار صحبت خواهد شد.

د) Active Directory Federation Services - AD FS :

AD FS به شرکت ها اجازه می دهد تا از اشتراک کاربری های دیگر در دایرکتوری خود استفاده کنند. در این خصوص در آینده بسیار صحبت خواهد شد. دو بهبود در این قسمت بسیار چشمگیر است:

1) پشتیبانی از Federation trust import/export : در گذشته فرایند وارد/ خارج کردن اطلاعات باید دستی صورت می گرفت اما اکنون علاوه بر امکان دستی، می توان بین دو AD FS این فرآیند می تواند ساده تر صورت گیرد.

2) AD FS deployment limiting  :  امکان محدود کردن ایجاد AD FS از طریق group policy .

ه) Active Directory Rights Management Services - AD RMS :

هر چند اسم این ویژگی تغییر پیدا نکرده اما واقعا با قبل غیر قابل مقایسه است. اکنون می توان با  AD RMS ، آفیس 2007 و اینترنت اکسپلورر 7 را نیز مدیریت کرد.

در پایان:
از انعطاف پذیری Active Directory در ویندوز سرور 2008 لذت ببرید و راحت مدیریت کنید

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

حوزه عملکرد جنگل ها در ویندوز سرور 2008

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

 در ویندوز سرور 2008 حوزه های عملکرد به این شکل است:

Windows 2000 forest function level :
دامین کنترلرهای مجاز: Windows server 2000, Window Server 2003, Windows Server 2008

Windows Server 2003 forest function level :
دامین کنترلرهای مجاز:  Window Server 2003, Windows Server 2008
- از تمام مزایای حوزه عملکرد Windows Server 2003 بهره مند خواهید شد مثل:Forest trust,Domain rename,Linked-value replication  و بسیاری دیگر.

Windows Server 2008 forest function level :
دامین کنترلرهای مجاز:   Windows Server 2008
- برخلاف حوزه عملکرد دامین ها، هیچ ویژگی جدیدی نصب به Windows Server 2003 forest function ندارد. اما بدیهی است که زمانی که تمام دامین کنترلرها ویندوز سرور 2008 اند از این حوزه استفاده خواهید کرد.

بالا بردن حوزه عملکرد جنگل ها در ویندوز سرور 2008 :

حوزه عملکرد جنگل تمام درخت ها و تمام دامین ها را تحت تاثیر قرار می دهد. برای بالابردن حوزه عملکرد جنگل باید ابتدا حوزه عملکرد تمامی دامین ها بالارود که نیازمند به روز رسانی جدی و در نتیجه، تامین منابع مالی و عملیات مدیریتی بسیاری است.

- در زمان نصب اکتیو دایرکتوری (اولین دامین در جنگل جدید) می توانید حوزه عملکرد مناسب را انتخاب کنید. تصویر 1 
بخوانید: آموزش نصب اکتیو دایرکتوری در ویندوز سرور 2008

- پس از نصب اکتیودایرکتوری می توان حوزه عمکرد جنگل را در دامین کنترلر Forest Root ارتقا داد.
1. برای این کار در کنسول Active Directory Users and Computers روی اولین گره در ساختار درختی کلیک راست کنید. و گزینه Raise Forest Functional Level را انتخاب کنید. تصویر 2
2. حوزه عملکرد مورد نظر خود را انتخاب کنید. تصویر 3
3. ضمن خواندن پیغام و توجه به آنکه این فرآیند برگشت ناپذیز است چنانچه می خواهید این کار را انجام دهید تایید کنید. تصویر 4
4. سپس گفته خواهد شد که با توجه به توپولوژی replication زمانی طول خواهد کشید که در کل جنگل اعمال شود. تصویر 5
5. اگر مرحله 1 را دوباره انجام دهید می توانید حوزه عملکرد فعلی را مشاهده کنید. تصویر 6

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

نصب نرم افزار روی تمام کامپیوتر های شبکه

در این مقاله قصد دارم روش نصب یک نرم افزار روی تمام یک Domain و یا OU را مورد بررسی قرار دهم. مسئله ساده ای است و بسیار کاربرد دارد. معمولا آنچه که می خواهیم روی کامپیوتر های کلاینت نصب کنیم سه دسته می شوند:

1. فایل های MSU که مربوط به به روز رسانی های ویندوز می شود. با WSUS آن ها را منتشر می کنیم و در اینجا بررسی نمی شوند.

2. فایل های MSI که با کمترین زحمتی قابل نصب روی تمام کلاینت های مورد نظر هستند و در اینجا روی این فایل ها تمرکز نمی کنیم.

3.فایل های غیر از MSI مانند EXE که می خواهیم روی تمام کلاینت های مورد نظر نصب شوند و قدری کار بیشتر نیاز است.

برای نصب یک نرم افزار باید مراحل زیر را طی کنیم.

- دسترسی به Group Policy مربوط به OU یا دامین ... مورد نظر. مثلا در کنسول Active Directory Users and Computers روی OU مورد نظر کلیک راست کرده و Properties را می زنیم. در زبانه Group Policy دکمه Edit را می زنیم.

- می دانیم قسمت Computer Configuration مربوط به کامپیوتر ها و قسمت User Configuration مربوط به User ها می باشد. بر اساس سناریو انتخاب می کنیم که از کدام یک استفاده کنیم. هرچند هریک محدودیت هایی دارند که در ادامه ذکر می شوند.

- باید یک Package برای نصب آماده کنیم. برای این کار روی Software Installation در قسمت مورد نظر کلیک راست می کنیم و سپس در New گزینه Package را انتخاب می کنیم. بر حسب آنکه فایل MSI است یا نه در اینجا باید مراحل مختلفی را انجام دهیم. اگر MSI باشد، فایل را انتخاب می کنیم و مراحل ساخت پکیج را ادامه می دهیم. اما اگر ZAP باشد باید ابتدا یک ZAP فایل بسازیم که در ادامه توضیح می دهم.

*مهم: در هنگام انتخاب مسیر فایل Installation و ZAP فایل فراموش نکنید و تاکید می کنم فراموش نکنید که مسیر فایل را در شبکه وارد کنید. مثلا از طریق My Network Places مسیر را وارد کنید یا مثلا :

\\Server1\office\word.msi

بنابراین بدیهی است که باید فایل ها Share باشند. البته اگر فراموش کنید، ویندوز با پیام هشداری به شما یادآوری می کند.

- پس از ساخت پکیج سه گزینه در دسترس داریم:

Published : اگر یک package به صورت published تنظیم شود، اولین باری که کاربر login کند Add Remove Program برای او نمایش داده خواهد شد و می تواند انتخاب کند که برنامه نصب شود یا خیر.

Assigned : اگر یک Package به صورت Assigned به کاربری تنظیم شود، اولین باری که کاربر Login کند برنامه نصب می شود و پیش از اولین بار اجرا نهایی می شود. اگر یک Package به صورت Assigned به کامپیوتری تنظیم شود، اولین باری که ویندوز ستارت می شود پکیج نصب می شود و پیش از اولین اجرا نهایی می شود. برای تمام کاربران آن کامپیوتر نرم افزار قابل دسترسی خواهد بود.

بدیهی است از آنجا که کامپیوتر ها نمی توانند تصمیم بگیرند که آیا یک پکیج نصب شود یا خیر، گزینه Published برای کامپیوتر ها غیر فعال است.

فایل های ZAP فقط می توانند برای کاربران یعنی در قسمت User Configuration تنظیم شوند. چرا که فایل های ZAP از برنامه نصب کننده اختصاصی خود استفاده می کنند و نمی توانند از elevated privileges استفاده کنند. بنابراین در هنگام نصب اگر Administrative Permission نیاز باشد تنها کاربرانی که دارای این مجوز هستند می توانند این فایل را نصب کنند . بنابراین باید Published شوند تا کاربری مراحل نصب را انجام دهد.

Advanced : تنظیمات اضافی را در اختیار قرار می دهد. بسیاری از نکات از جمله Advanced را فعلا صرف نظر می کنیم.

توجه : به نسخه های 32 بیتی و 64 بیتی توجه کنید.

ساختن یک ZAP فایل:
Zap فایل یک فایل متنی است که بنابراین می تواند به راحتی با Notepad و یا هر ویرایشگر متن دیگری نوشته شود. در اینجا دو مثال برای ساخت Zap فایل ارائه می دهم. مثال اول کوتاه، خلاصه و کافی است و در مثال دوم اطلاعات بیشتری ارائه شده.

* به آسانی کد زیر را در NotePad کپی پیست کنید و تغییرات لازم را انجام دهید و آن را با پسوندzap ذخیره کنید. در این مثال Excel 2007 را نصب می کنیم. دقت کنید که فایل را با پسوند zap.txt به اشتباه ذخیره نکنید.

[Application]
FriendlyName = "Microsoft Excel 2007"
SetupCommand="\\server5\share\Excel 2007\setup.exe"

کد های مربوط به یک ZAP فایل - مثال 1

و در مثال بعد که قسمتی از مقاله ای است که در Help & Support آمده کاملا تمام موارد در دسترس توضیح داده شده

[Application]
; Only FriendlyName and SetupCommand are required,
; everything else is optional.

; FriendlyName is the name of the program that
; will appear in the software installation snap-in
; and the Add/Remove Programs tool.
; REQUIRED
FriendlyName = "Microsoft Excel 97"

; SetupCommand is the command line used to
; run the program's Setup. With Windows Server 2003
; and later you must specify the fully qualified
; path containing the setup program.
; Long file name paths need to be quoted. For example:
; SetupCommand = "\\server\share\long _ ; folder\setup.exe" /unattend
; REQUIRED SetupCommand = "\\server\share\setup.exe"

; Version of the program that will appear
; in the software installation snap-in and the
; Add/Remove Programs tool.
; OPTIONAL
DisplayVersion = 8.0

; Version of the program that will appear
; in the software installation snap-in and the
; Add/Remove Programs tool.
; OPTIONAL
Publisher = Microsoft

کد های مربوط به یک ZAP فایل - مثال 2

برای اطلاعات بیشتر می توانید به اینجا + + + + + + مراجعه کنید.(مقالاتی در Technet و Help & Support)

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

تغییر نام دامین کنترلر

 

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

تذکر: این کار نام دامین را تغییر نمی دهند. برای تغییر نام دامین باید از RENDOM استفاده کنید که حالا دیگر جزء اجزایی شده که به صورت پیش فرض همزمان با نصب AD DS استفاده کنید.

توجه: دامین کنترلر هایی که Certificate Authority مایکروسافت را دارند، نمی توان rename کرد.

توجه: تغییر نام دامین کنترلر نیز مشابه همیشه نیاز به ریستارت شدن دارد. بنابراین باید شرایط قطع سرویس در نظر گرفته شود.

توجه: حوزه عملکرد دامین برای تغییر نام دامین کنترلر حداقل باید Windows Server 2003 باشد. البته تغییر نام دامین کنترلر های ویندوز 2000 نیز امکان پذیر است، اما نه با این روش.

برای تغییر نام یک دامین کنترلر، از ابزار NETDOM استفاده می کنیم. در ویندوز سرور 2008 قسمتی از سیستم عامل است، اما در نسخ قبلی باید آن را دانلود کنید و یا از سی دی ویندوز سرور 2003 آن را نصب کنید. (نصب support tools)

برای تغییر نام دامین کنترلر ابتدا یک FQDN به عنوان یک اسم جدید کامپیوتر اضافه می کنیم. سپس تمام اشتراک های کامپیوترها (computer accounts) مربوط DC باید شامل خصوصیت ( service principal name ( SPN به روز شده باشند و تمام DNS سرورها برای نام دامین باید دارای رکورد A برای نام جدید کامپیوتر باشند. هر دو اسم اضافه شده و فعلی کامپیوتر تا هنگامی که اسم فعلی کامپیوتر حذف نشود، به عنوان نام کامپیوتر هستند. این روش هیچ وقفه ای برای کاربرها در برقراری ارتباط یا authenticate ایجاد نمی کند تا وقتی که دامین کنترلر ریستارت شود.

خط فرمان ( Command Prompt) را باز کنید. مثلا در run وارد کنید cmd .

1. اضافه کردن نام مورد نظر: دستور مقابل را وارد کنید تا یک اسم جدید، اضافه کنید.

netdom computername CurrentComputerName /add:NewComputerName

در این دستور NewComputerName اسم جدید است و CurrentCumputerName اسم فعلی است.

2. انتظار! : دستور فوق، ویژگی (SPN) در اکتیو دایرکتوری را برای این کامپیوتر به روز رسانی می کند و رکوردهای DNS برای اسم اضافه شده را ثبت می کند. مقدار SPN اکانت کامپیوتر باید در Domain همه DCها replicate شود و رکورد DNS برای اسم اضافه شده باید در تمام DNS سرورها بخش شود. اگر حذف اسم فعلی کامپیوتر پیش از این اتفاق باشد، بعضی از کلاینت ها قادر به برقراری ارتباط با این سرور نخواهند بود. بنابراین باید منتظر ماند تا Replication Application فرآیند کپی کردن را تمام کند. می توان این را با استفاده از ابزارهایی همانند REPADMIN و REPLMON بررسی کرد.

می توان اسم اضافه شده به Computer Object را با ADSIEDIT.MSC بازبینی کرد. به Computer Object رفته و روی آن رایت کلیک کرده، Properties را بزنید. اسکرول لیست ویژگی های موجود را پائین ببرید تا اینکه به خصوصیتی به نام MSds-AdditionamDnsHostName برسید. در ویندوز سرور 2008 ابزار ADSIEDIT.MSC به صورت پیش فرض نصب شده است.

3. انتخاب نام اصلی: با استفاده از دستور زیر، نام اضافه شده را نام اصلی کامپیوتر خواهیم کرد و حتما مرحله 2 را پیش از انجام این مرحله انجام داده ایم!
 

netdom computername CurrentComputerName /makeprimary:NewComputerName

4. ریستارت: اکنون باید دامین کنترلر را ریستارت کنید.

5. حذف کردن: حال نام قبلی را حذف می کنیم. دستور زیر را وارد کنید:

netdom computername NewComputerName /remove:OldComputerName

* در اینجا توجه کنید OldComputerName نام قبلی دامین کنترلر است.

6. بررسی: هرچند قطعا بدون مشکل تا اینجا پیش رفته اید و احتمالا با مشکلی هم رو به رو نخواهید شد، اما پیشنهاد می کنم اطمینان پیدا کنید که Replication به درستی انجام شود

 

 

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

 

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

یک سرویس  دایرکتوری تقریبا مشابه یک دیتابیس است. در یک دایرکتوری اشیائی که به نوعی مرتبط اند، ذخیره می شوند و از طریق صفاتشان قابل دسترسی اند. در سرویس های مختلف و در سیستم عامل های مختلف، از یک سرویس دایرکتوری استفاده می شود. در سرویس دایرکتوری اطلاعات به صورت سلسه مراتبی نگه داری می شود همچنین سرویس دایرکتوری تمامی اطلاعات لازم را نگه داری می کند. با توجه به ارتباط میان اشیاء، دسترسی از طریق صفات و نگه داری تمامی اطلاعات لازم، مدیریت اطلاعات مرکزی و آسان تر می شود.

در شبکه های گوناگون همانند اینترنت، اشیاء مختلفی با استفاده از سرویس دایرکتوری نگه داری می شوند. سرویس هایی همانند فایل سرور ها و فکس سرور ها از دایرکتوری بهره می برند. اما عمکرد یک سرویس دایرکتوری در سرویس های مختلف، متفاوت است. با توجه به اهمیت این سرویس، باید مکانیسم های امنیتی و مدیریتی دیگر برای یکپارچگی و حفظ حریم خصوصی اتخاذ شود که در نتیجه باید از پروتکل ها و سرویس های جانبی دیگر نیز استفاده شود.

 

Active Directory Domain Service - AD DS :

سرویس دامین اکتیو دایرکتوری ، موجود در ویندوز نسخ سرور، شامل یک سرویس دایرکتوری است که اطلاعاتی همچون منابع و… را ذخیره می کند. اشیاء مختلفی در اکتیو دایرکتوری ذخیره می شود که به صورت اشیائی متفاوت سازمان می یابد. هر شیئ مجموعه مجزایی از صفات است که اشیائی از شبکه را مشخص می کند. به عنوان مثال یک User Account می تواند شامل ویژگی هایی همچون نام، نام خانوادگی و نام Logon باشد. در حالی که یک Computer Account شامل ویژگی های همچون نام و مشخصات می تواند باشد. بنابراین ضمن تفاوت اشیاء ویژگی ها متفاوت است و مشخص کننده اشیاء مختلفی از شبکه هستند. با بیان دقیق تر می توان گفت : هر داده ای که در Active Directory ذخیره می شود، به صورت اشیائی متمایز و دارای صفاتی جداگانه ذخیره می شود. برخی اشیاء خود می توانند شامل اشیائی دیگر باشند که با آنها Container گفته می شود به عنوان مثال یک دامین، یک Container است که خود شامل اشیائی دیگر همانند کامپیوتر ها یا کاربران می تواند باشد.

 

 

Active Directory Schema :

Active Directory schema معین کننده اشیائی است که می تواند در اکتیو دایرکتوری ذخیره شوند. Schema لیستی از انواع اشیاء و انواع داده های مربوط به آن اشیاء است، که می تواند در اکتیو دایرکتوری ذخیره شود. هر Schema به وسیله دو شیئ معین می شود:

1. schema class objects که schema classes نیز گفته می شود: مشخص کننده اشیائی است که امکان ساخت آن در اکتیو دایرکتوری وجود دارد.

2. schema attribute objects که schema attributes نیز گفته می شود. مشخص کننده ی ویژگی کلاس هایی است که عضو شده اند.

این دو شیئ با هم دیگر، metadata گفته می شوند.

 

یک schema class در واقع یک قالبی برای ساختن اشیاء جدید در اکتیو دایرکتوری است. هر schema class جمعی از schema attributes  است که در زمان ساخت یک شیئ جدید، مقادیر ویژگی ها تغییر پیدا می کند به عنوان مثال یک کلاس User شامل ویژگی ها مختلفی است همانند Home Folder . بدیهی است که هر schema attribute نیز صرفا معین کننده ی یک ویژگی از ویژگی های شیئ است. چندین ویژگی و کلاس مختلف به صورت پیش فرض Schema وجود دارد. امکان افزودن کلاس و ویژگی جدیدی که وجود ندارد، نیز وجود دارد. با توجه به آنکه یک Schema نمی تواند حذف شود، (فقط می تواند غیر فعال شود) باید در توسعه دادن Schema بسیار دقت شود.

 

 

اجزای Active Directory :

احزای مختلفی در اکتیو دایرکتوری نفش دارند. این اجزاء فیزیکی یا منطقی هستند به این سبب، اکتیو دایرکتوری دارای ساختار فیزیکی و منطقی است.

ساختار منطقی:

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

 

1. دامین (Domain – دامنه):

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

1. تمام اشیاء شبکه در یک دامین قرار دارند و هر دامین تنها اطلاعات مربوط به خود را دارا است.

2. یک دامین، یک محدوده امنیتی است. دسترسی به اشیاء دامین ها از طریق ACL ( لیست کنترل دسترسی – Access Control List) امکان پذیر می شود. در واقع تنها اشیائی قابلیت دسترسی دارند که در ACL موجود و دارای یک ACE باشند. این لیست مشخص می کند که کدام کاربر و در چه سطحی به دسترسی دارد.ACE کوتاه شده ی Access Control List است.

 

2. واحد های سازمان ( OU – Organization Unites ):

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

3.درخت ها (Tree) :

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

 

4. جنگل ها (Forest) :

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

 

 

ساختار فیزیکی:

1.سایت (Site) :

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

معمولا یک سایت به یک LAN پایان می پذیرد و از طریق یک MAN یا WAN به سایت دیگری متصل می شود هر چند الزاما چنین نیست. زمانی که سایت ها قسمتی از فضای نامی نباشد، در استفاده از منابع گروه بندی اجزاء را گروه بندی دامین، فرزند-دامین و… مشاهده خواهید کرد و در مشاهده منابع وجود سایت ها را ممکن است احساس نکنید. در آینده در خصوص سایت ها با تفصیل صحبت خواهد شد.

 

2.دامین کنترلر (Domain Controller – DC):

دامین کنترلر یک کامپیوتری است که ویندوز نسخه سرور روی آن نصب شده است و Active Directory Domain Service روی آن در حال اجرا است. هر دامین کنترلر فقط می تواند یک دامین را سرویس دهد ولی هر دامین می تواند شامل تعدادی دامین کنترلر باشد. وظیفه ی شناسایی کاربران بر عهده Domain Controller ها است و به صورت مرکزی انجام می شود که در این خصوص در آینده بیشتر صحبت می شود.

هر دامین کنترلر یک کپی کامل از اطلاعات موجود در اکتیو دایرکتوری را نگه داری می کند. همچنین تغییرات خود را با سایر دامین کنترلرها Replicate می کند. در خصوص replication نیز در آینده صحبت می شود.

Global Catalog چیست؟

اکتیو دایرکتوری امکان یافتن منابع همانند پرینتر ها، فایل ها و کاربران را فراهم می کند. یک سرویس کاتالوگ، شامل اطلاعات برگزیده ای از هر دامین در خصوص هر شیئ است. Global Catalog سرویسی است که در اکتیو دایرکتوری برای یافتن منابع استفاده می شود. Global Catalog یک انبار مرکزی اطلاعات است که اطلاعات گزینش شده ای در خصوص اشیاء موجود در یک جنگل، درخت یا دامین را شامل می شود. به صورت پیش فرض Global Catalog روی اولین دامین کنترلر در جنگل (Forest) جدید ساخته می شود. دامین کنترلری که این انبار اطلاعات روی آن قرار داشته باشد، Global Catalog Server گفته می شود. در یک جنگل می توان هر دامین کنترلری را به عنوان Global Catalog Server تنظیم کرد. از آنجایی که از مکانیسم Multi Master در Replication استفاده می شود، مشکلی در همسان سازی اطلاعات به وجود نخواهد آمد. به صورت پیش فرض این اطلاعات گزینش شده، اطلاعاتی است که بیشتر مورد جستجو قرار می گیرد. همانند نام و نام خانوادگی کاربران. این صفات در Active Directory Schema معین می شوند. همانطور که گفته شد، یکی از وظایف Global Catalog فراهم آوردن امکان جستجو و یافتن اطلاعات است. از آنجایی که اطلاعات سراسر یک جنگل در دسترس است، بدون توجه به آنکه شیئ در چه دامینی است می توان به جستجو  پرداخت.

 

بر خلاف تصور، این تنها وظیفه یک Global Catalog Server نیست. یک Global Catalog Server در Logon شدن کاربران نیز می تواند نقش داشته باشد. در برخی Functional Level ها، دامین کنترلر در زمان logon باید در خواست اطلاعات universal group membership کند که از Global Catalog Server انجام می شود. همچنین اگر از UPN در جنگلی که بیشتر از یک دامین دارد استفاده شود، استفاده از Global Catalog Server برای resolve کردن نام کاربر تنها راه حل است.

Cashe کردن Universal Group Membership: در یک جنگلی که بیش از یک دامین دارد، در سایت هایی که Global Catalog Server ای وجود ندارد، باید از این ویژگی استفاده کرد. این ویژگی سبب می شود تا از درخواست مجدد universal group memberships از طریق لینک WAN که معمولا سرعت پایین و ترافیک بالایی دارد جلوگیری شود. تذکر آنکه برنامه ریزی برای لینک های WAN و MAN در یک اکتیو دایرکتوری از مهم ترین کارهایی است که یک مدیر شبکه باید انجام دهد. تنظیم صحیح سایت ها با دامین کنترلر ها و گلوبال کاتالوگ سرور ها از مهمترین این نکات هستند.

در جستجو آدرس بوک Exchange نیز، حتی Global Catalog Server کاربرد دارد. برای دسترسی به Global Access List یا GAL از Global Catalog Server استفاده می شود.

 

چگونه یک Global Catalog Server ایجاد کنیم؟

همانطور که گفته شد، یک Global Catalog Server باید یک دامین کنترلر باشد، بنابراین پیش نیاز تنظیم Global Catalog Server نصب اکتیو دایرکتوری و راه اندازی دامین کنترلر است. از آنجایی که به صورت پیش فرض اولین دامین کنترلر در جنگل جدید، Global Catalog Server است، باید برای ایجاد یک گلوبال کاتالوگ سرور دیگر، حداقل دو دامین کنترلر داشته باشیم. همانطور که گفته شد، اهمیت تنظیم Global Catalog Server زمانی است که چند سایت در دامین داریم به ایا علت از طریق کنسول Active Directory Sites & Services به مدیریت می پردازیم.

1. کنسول Active Directory Site and Services را از طریق Administrative Tools باز می کنیم.

2. روی سایتی که دامین کنترلر مورد نظر روی آن قرار دارد در نوار سمت راست دابل کلیک کنید.

3. روی Servers دابل کلیک کنید و روی NTDS Settings کلیک راست کنید و Properties را بزنید.

4. در زبانه (Tab) عمومی general چک باکس global Catalog را چک بزنید.

5. دامین کنترلر را Restart کنید و دامین کنترلر، Global Catalog Server هم از این پس خواهد بود. در Restart کردن Domain Controller شرایط راه اندازی مجدد یک سرور را فراموش نکنید.

 

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

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

سایت ها در اکتیو دایرکتوری

پیش از این در خصوص ساختار اکتیو دایرکتوری صحبت کردیم، یکی از مهمترین اجزاء این ساختار سایت ها هستند. برنامه ریزی سایت ها بسیار حساس است و با دقت خاصی باید انجام شود. در اینجا برخی از این مسائل را بررسی می کنیم. برای بیشتر مدیران، سایت یک بخش فیزیکی از زیرساخت شبکه است. به عنوان مثال از دفتر سازمان در یک شهر گرفته تا طبقه ای از یک ساختمان. سایت ها از طریق یک لینک به سایر بخش های شبکه متصل است. ممکن است برای ارتباط سایت ها از چند لینک مختلف استفاده شود و لینک ها هم می توانند به سادگی یک Dial-up باشند یا می توانند ارتباط بی سیم، ارتباط از طریق ماهواره یا فیبر نوری باشند. بدون توجه به آنکه یک لینک با چه زیرساختی ایجاد می شود، زیرساخت شبکه در ساختار اکتیو دایرکتوری دارای اهمیت است. در هر شرایط باید راهکارهایی را اتخاذ کرد که بیشترین اثر بخشی را در مدیریت ترافیک داشته باشند.

 

در واقع  یک سایت دسته ای  از IP subnet ها است. معمولا در یک سایت از تکنولوژی های ارتباطی LAN بهره می بریم و با استفاده از تکنولوژی های ارتباطی MAN یا WAN به یک سایت دیگر متصل می شویم. لینک ارتباطی MAN یا WAN بین دو سایت را Site Link می گوییم. با اینکه دو واژه ی Site و Site Link معنای کاملا متفاوتی دارد به اشتباه برخی به جای همدیگر به کار می برند که باید از آن پرهیز کرد. گاها گفته می شود مرزهای یک سایت  مرزهای یک LAN است که با یک WAN به یک LAN دیگر متصل است. هر چند بیان درست است اما این سناریوی متداول است و همواره یک سایت چنین شرایطی را ندارد. حتی الزاما یک Site Link با استفاده از WAN Technology نیست. در سناریو های متفاوتی می توان از سایت ها استفاده کرد. امروزه Trust ها در سایت ها بی اثر اند، اما ممکن است در آینده امکان ایجاد Trust بین دو سایت ایجاد شود هر چند پروتکل های مورد استفاده در اکتیو دایرکتوری امروز این مسئله را قدری دور از ذهن می کنند. همچنین سایت ها به دامین ها هیچ ربطی ندارند. در واقع این جمله برای تاکید بیشتر روی مسئله ی آنکه یک سایت می تواند شامل چند دامین باشد و یا یا دامین می تواند شامل چند سایت باشد نوشتم.

 

معمولا لینک های با سرعت پایین تر از 512 Kbps لینک کم سرعت در نظر گرفته می شوند. هر چند از آنجایی که اکثر خطوط بین شهری و خطوط شهری به صورت اجاره ای از شرکت های مخابراتی است، هنوز خطوط کم سرعت متداول ترند. لینک های بین شهری اغلب کیفیت ارتباطی بالایی ندارند لذا باید در مدیریت لینک ها دقیق عمل کرد. مسئله دیگر هزینه استفاده از خطوط است. گاهی شرکت های مخابراتی در ازای ترافیک هزینه دریافت می کنند و یا ممکن است حجمی رایگان باشد و بیش از آن مستلزم پرداخت  مبلغی باشد. در این خصوص نیز باید دقت شود که لینک ارزان قیمت تر، کم ترافیک تر و… در اولویت است. فاکتوری به نام COST را برای مدیریت لینک ها در اختیار داریم. لینکی که دارای COST کمتری است در اولویت قرار خواهد داشت.  با توجه به این مسئله دو عامل بزرگترین انگیزه برای ایجاد سایت ها است:

 

ترافیک replication :

Replication منتقل کردن تغییرات رخ داده روی دامین کنترلر ها است. به عنوان مثال زمانی که یک User جدید ایجاد می شود، این کاربر باید روی دامین کنترلر های دیگر نیز ساخته شود.  بنابراین این امر ترافیکی را در شبکه ایجاد می کند.  این ترافیک دو نوع مختلف دارد. از لحاظ تئوری برخی تغییرات  در زمان اتفاق افتادنشان باید به سرعت بین دامین کنترلر ها  Replicate شوند.

 

محلی کردن سرویس دهی:

اگر شبکه در دو محل فیزیکی مختلف باشد، با قرار دادن یک دامین کنترلر در هر کدام از این محل های فیزیکی، به علت پیش فرض Load Balance در اکتیو دایرکتوری نمی توان معین کرد کاربران برای Authentication  از کدام دامین کنترلر استفاده کنند. اما با استفاده از سایت ها می توان در انتخاب دامین کنترلر، کلاینت را هدایت کرد. به عبارت  بهتر، با قرار دادن یک دامین کنترلر در هر سایت، کلاینت ها را در استفاده برای استفاده از دامین کنترلر موجود در سایت خود تشویق می کنیم. اگر دامین کنترلر در سایت خود در دسترس نباشد آنگاه از دامین کنترلر در سایت دیگر استفاده خواهند کرد.

 

تذکر مهم: از آنجایی که اهداف ذکر شده در شرایطی محقق می شوند که در هر سایت یک دامین کنترلر موجود باشد، در صورتی که  دامین کنترلر موجود نباشد در بسیاری از مواقع مفید نخواهد بود اما همواره چنین نیست. در واقع در اکثر شرایط مختلف وجود یک دامین کنترلر توصیه می شود. ضمن آنکه اگر Site Link با اختلال رو به رو شود که احتمال پایینی ندارد (خصوصا در ایران) وجود یک دامین کنترلر در سایت می تواند بسیار مفید باشد. در بیشتر مواقع در سایت های کوچک و branch office ها استفاده از یک Read-Only Domain Controller بهترین تصمیم است. به این صورت اگر سایت لینک اختلال داشته باشد، دامین کنترلر داخلی سایت در دسترس است و اگر دامین کنترلر اختلال داشته باشد، اگر سایت لینک اختلال نداشته باشد دامین کنترلر سایت همسایه در سایت مفروض سرویس دهی خواهد کرد. هر چند می توان از Additional Domain Controller نیز در یک سایت بهره برد.

 

جمعیت کاربران:

یکی دیگر از انگیزه های ایجاد سایت می تواند تعداد زیاد کاربران باشد. با این کار می توان ترافیک را تقسیم کرد و کاربران پراهمیت تر از Subnet که معمولا در آن حضور دارند به مشکلاتی که از ترافیک بالای دامین کنترلر برای آنها ایجاد می کند رو به رو نشوند. هرچند اگر در Subnet شلوغ تر Login کنند ممکن است با همان مشکلات رو به رو شوند. با توجه به هزینه های انجام این کار، زمامی که تعداد کاربران زیاد است و یا حجم کاری زیادی به دامین کنترلر وارد می کنند یک راه حل است. در حالی که زمانی امکانات سخت افزاری دامین کنترلر جوابگو نیست، می توان سخت افزار های قدرتمند تری تهیه کرد راهکار ایجاد سایت ها نیز راهکاری است که برخی مدیران شبکه  طرفدار آن هستند.

 

ایجاد یک سایت:

مدیریت سایت ها، replication و برخی مسائل دامین کنترلر ها را از طریق کنسول Active Directory Sites and Services انجام می شود. به صورت پیش فرض یک سایت به نام Default-First-Site-Name و یک سایت لینک به نام  Defaultsitelink وجود دارد. برای ساختن یک سایت جدید روی Sites کلیک راست کنید و new site را بزنید. نام سایت و لینک یا لینک هایی که آن سایت را به سایر سایت ها متصل می کند را انتخاب کنید.

 

اما سایت ها زمانی مفید خواهند بود که کلاینت ها و سرور ها بدانند در یک سایت هستند. این کار با معین کردن IP آدرس های هر سایت انجام می شود. به عبارت دیگر باید هر سایت یک Subnet نیز باشد و سپس با افزودن یک subnet در کنسول Active Directory Sites and Services معین می کنیم که هر Subnet مربوط به چه سایتی است. برای اضافه کردن یک Subnet روی Subnets کلیک راست کنید و گزینه New Subnet را بزنید. مشابه مثال20/ 157.54.208.0 NetID و SubnetMask را وارد کنید و سایتی که آن subnet به اختصاص دارد را انتخاب کنید.

 

پس از افزودن یک لینک در properties سایت مربوطه قابل مشاهده است. هرچند از اینجا نمی توانید آن را تغییر بدهید. برای این کار باید به properties همان subnet مراجعه کنید. در محیط عملیاتی توجه داشته باشید که تمام Subnet ها را در یک سایتی اضافه کرده باشید. عدم وجود یک Subnet باعث می شود کلاینت متوجه نشود در کدام سایت است و باعث مشکلات performance و ترافیک می شود.

 

مدیریت دامین کنترلر ها در سایت ها:

زمانی که اولین دامین کنترلر در جنگل جدید را ایجاد می کنید، به صورت پیش فرض سایتی به نام default-first-site-name ایجاد می شود و Domain Controller در آن سایت قرار می گیرد. پس از آن اگر سایت هایی ایجاد کنید، دامین کنترلر ها برحسب IP address خود در سایت های مربوط به Subnet خود اتوماتیک قرار می گیرند. توجه داشته باشید servers در کنسول Active Directory Sites and Services فقط DC ها را نمایش می دهد. همانطور که گفته شد تنها به دامین کنترلر ها می گوییم سرور و بقیه سرور ها را کامل بیان می کنیم مثلا DHCP server . هر سایت یک کانتیتر سرور برای خود دارد. می توانید با move کردن و یا drag & drop یک دامین کنترلر را در یک سایت قرار دهید. اگر یک سایت شامل دامین کنترلر نباشد یا دامین کنترلر آن سایت down شود کاربران هنوز می توانند authenticate شود چرا که در دامین کنترلر سایت همسایه یا یک دامین کنترلر دیگر در دامین استفاده می کنند.

 

 

 

چگونه کلاینت ها به دامین کنترلر محلی خودشان هدایت می شوند؟

این یکی از سوالاتی است که از لحاظ تکنولوژیک بسیار جالب است. خیلی خلاصه در اینجا بحث می کنم این قسمت در حل مشکلات پیش آمده بسیار مفید است و با توجه به عدم توجه بسیاری مدیران، قدری کم توجهی به این مسئله جالب شده است.  زمانی که یک دامین کنترلر در یک سایت قرار می گیرد، تبلیغ می کند که من اینجا هستم، برای authenticate به من مراجعه کنید. حال اگر آن دامین کنترلر آنجا نباشد مثلا down شده باشد، قطعا مشتریان یا کلاینت ها به سراغ یک دامین کنترلر دیگر می روند.زمانی که یک دامین کنترلر به دامین اضافه می شود برای آنکه کلاینت از توانایی دامین کنترلر مطلع شوند رکورد های DNS ای را ثبت می کند. این رکورد ها از نوع ( SRV ( Service Locator هستند. در رکورد های SRV بر خلاف A record ها مشخص می شود که چه سرویسی توسط چه host name ای انجام می شود. دامین کنترلر قابلیت خود را با درست کردن رکورد های SRV و با نام های kerberos_ و LDAP_ برای کلاینت ها آشکار می کنند. این رکورد ها را در جاهای مختلفی در  DNS ثبت می کنند.

 

اول: رکورد ها را در پوشه ی tcp_ ثبت می کنند.
دوم : رکورد ها را در پوشه TCP_ درنام سایت خود ثبت می کنند.
سوم: رکورد های دیگری هم در msdcs_ ثبت می شود. این zone شامل دامین کنترلر های مایکروسافت می شود.

 

بر اساس RFC 2052 یک رکورد SRV حداقل شامل:

1. نام و پورت :  در ویندوز سرور 2008 شامل ldap پورت 389 ؛ Kerberos پورت 88 ؛ KPassWD پورت 646 و GC پورت 3268 در خصوص دامین کنترلر ها است. KPassWD کوتاه شده ی Kerberos PassWord است و GC کوتاه شده ی Global Catalog است.

2. پروتکل : پروتکل لایه انتقال ( Transport ) باید مشخص شود که TCP یا UDP می تواند باشد که هر دوی آنها ثبت می شود. کلاینت های مایکروسافت از TCP استفاده می کنند اما UNIX از UDP هم می تواند استفاده کند.

3. Host Name : مشخص کننده ی یک Host Name است که IP Address ان از طریق یک  A record دیگر مشخص می شود. نکته جالب آن است که زمانی که یک Query برای یک رکورد SRV ارسال می شود، DNS Server خودکار جواب رکورد A مربوطه را نیز ارسال می کند تا Query دیگری دوباره ارسال نشود.

 

تصور کنید الان یک کلاینت جدید را عضو دامین می کنیم. تنظیمات IP آن Automatic است و از یک DHCP Server یک IP و… دریافت می کند. کلاینت restart می شود و اکنون آماده است که یک user تشخیص هویت شود و کاربر وارد desktop خود شود. حال کلاینت از کجا باید یک دامین کنترلر پیدا کند؟ کلاینت یک Query به DNS Server ای که DHCP Server به او معرفی کرده می فرستد. Query ارسال شده برای بخش tcp_ است که همانطور که در قبل توضیح داده شد، شامل تمام دامین کنترلر ها می شود. DNS Server هم IP آدرس تمام دامین کنترلرها را به کلاینت می دهد. اولین دامین کنترلری که جوابی به کلاینت ارسال کند از روی Subnet های معین شده به کلاینت می گوید که در کدام سایت قرار دارد. کلاینت هم نام سایت را در Reistry خود ذخیره می کند و حال به DNS Server یک Query برای دامین کنترلر سایتی که در آن حضور دارد ارسال می کند. DNS Server با توجه به آنچه گفته شد، می داند کدام دامین کنترلر در کدام سایت است پس جواب Query را به کلاینت باز می گرداند. کلاینت اکنون از تمام دامین کنترلر های سایت خود در خواست authenticate می کند و هر دامین کنترلری که اول جواب دهد او تشخیص هویت کاربر را انجام می دهد. این اولین Startup پس از عضویت در دامین بود.

 

از آنجا که دامین کنترلر سریع تر از بقیه جواب داده بود، کلاینت به این دامین کنترلر علاقه مند می شود و در دفعات بعدی تلاش می کند تا با همین دامین کنترلر authenticate شود. اگر این دامین کنترلر در دسترس نبود آنگاه کلاینت به اجبار یک Query به DNS Server می فرستد و از دامین کنترلر های سایت خود سوال می کند و دوباره همان مراحل در خصوص یک دامین کنترلر دیگر اتفاق می افتد. اما اگر یک کامپیوتر قابل حمل همانند یک Laptop باشد چه اتفاقی می افتد؟ تصور کنید که Laptop در سایت A یکبار Authenticate شده و اکنون از سایت A به سایت B می رود. از آنجایی که Laptop به دامین کنترلر سایت A علاقه مند شده بود، ابتدا تلاش می کند که با دامین کنترلر سایت A تشخیص هویت شود حال آنکه در سایت B است و دامین کنترلر A به Laptop تذکر خواهد داد که سایت جدید شما B است به دامین کنترلر مربوط خودتان مراجعه کنید. Laptop هم به DNS Server یک Query می فرستد و از دامین کنترلر های سایت B سوال می کند.

 

اما اگر هیچ دامین کنترلری در سایت C موجود نباشد چه می شود؟ در این شرایط دامین کنترلر های نزدیک رکورد SRV خود را در سایت C ثبت می کنند. به این فرآیند Site Coverage گفته می شود. توضیح دقیق تر آنکه سایتی که دامین کنترلر نداشته باشد توسط دامین کنترلر سایتی پوشش داده می شود که کمترین Cost برای Site Link آن تنظیم شده باشد. هر چند می توانید به صورت دستی هم با تنظیم priority در رکورد های DNS این روند را تغییر دهید. اگر دامین کنترلر یک سایت down شود، سایت همسایه می تواند در آن سایت به سرویس دهی بپردازد.

 

ایجاد یک سایت لینک:

همانطور که گفته شد، به صورت پیش فرض یک سایت لینک با نام DefaultSiteLink وجود دارد. سایت لینک ها خودکار ایجاد نمی شوند و باید برای مدیریت Replication بین سایت ها و… سایت لینک ها به خوبی مدیریت شوند. در خصوص آنکه چگونه سایت لینک روی Replication اثر می گذارند در آینده بحث می کنیم. اما می توانید در هر سایت لینک فاصله زمانی یک Replication با Replication بعدی را معین کنید. همچنین با استفاده از Schedule می توانید معین کنید Relication فقط در ساعات خاصی اتفاق بی افتد. نکته قابل توجه آن است که حتی اگر Time Zone ها بین دو سایت یکسان نباشد، از آنجایی که ساعت بر حسب local time zone مشخص می شود و (Coordinated Universal Time (UTC ذخیره می شود. این به معنای آن است که در سایت دوم، زمان بی مشکل مشخص خواهد شد. اما در هر دو سایت برای پیشگیری از بروز مشکلی بهتر است مسئله را مانیتور کنید.

 

یک سایت لینک خاصیت تعدی دارد. همانند ریاضی که اگر a بتواند b را نتیجه دهد و b بتواند c را نتیجه دهد، a می تواند c را نتیجه دهد. اگر سایت a و b یک سایت لینک داشته باشند و سایت b و c هم یک سایت لینک داشته باشد، سایت a به سایت c متصل در نظر گرفته می شود. می توان خاصیت تعدی (Transitive) را فعال را غیر فعال کرد. به صورت پیش فرض برای هر نوع transport فعال است. به عنوان مثال تمام لینک های موجود در IP با هم دیگر خاصیت تعدی دارند. توجه کنید که اگر خاصیت تعدی را برای یک Transport غیر فعال کنید برای تمام سایت لینک های موجود در آن Transport غیرفعال می شود و باید به صورت دستی Site Link Bridge بسازید تا بتوانید از خاصیت تعدی استفاده کنید.  اما دلایل غیر فعال کردن خاصیت تعدی چه می تواند باشد؟

 

1. می خواهید کنترل کامل روی replication بین سایت ها داشته باشید.

2. Routing به صورت کامل در بین سایت ها برقرار نیست.

 

برای غیر فعال کردن خاصیت تعدی روی Transport مورد نظر کلیک راست کنید و گزینه properties را بزنید. سپس در زبانه(Tab) عمومی (general) گزینه Bridge all site links چک مارکش را بردارید. حال چگونه چند لینک را Bridge کنیم؟ با Bridge کردن دو یا چند سایت لینک در زمانی که خاصیت تعدی فعال است، خاصیت تعدی را برای چند سایت لینک ایجاد می کنیم . همچنین از آنجا گزینه Bridge all site links به صورت پیش فرض فعال است، Bridge کردن سایت لینک ها بدون غیر فعال بودن گزینه مذکور هیچ اثری نخواهد داشت.  برای ساختن پل میان دو سایت لینک، روی transport مورد نظر کلیک راست کنید و گزینه New Site Link Bridge را بزنید. یک نام انتخاب کنید و سپس سایت لینک هایی که می خواهید خاصیت تعدی داشته باشند را انتخاب کنید.

 

یکی از سوالتی که برخی افراد دارند آن است که تفاوت میان IP و SMTP و RPC در Transport ها چیست؟ که در این خصوص در آینده و در بحث Replication صحبت خواهد شد.

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

آشنایی با Active Directory Partitions

بررسی Active Directory Partitions :

همانطور که گفته شد، سرویس دایرکتوری برای نگه داری اطلاعات از Data Store های متعددی استفاده می کند به ویژه یک پایگاه داده (DataBase) به نام ntds.dit.  اطلاعاتی که در دایرکتوری ذخیره می شود، به صورت منطقی در بخش هایی به نام Partition (پارتیشن) جای می گیرند. به هر پارتیشن، Naming Context نیز گفته می شود. این بخش های منطقی یا Parition واحد هایی هستند که در Replication استفاده می شوند. برخی از این پارتیشن ها عبارتند از:

 

Domain Partition : این پارتیشن معرف هر آنچه در دامین وجود دارد می باشد. همانند (Users ، Computers ، Group policy Containers (GPCs . این اطلاعات در هر دامین مخصوص خودش است و  بین دامین های دیگر Replicate نمی شود، اما بین تمام دامین کنترلر های همان دامین Replication می شود. متداول است که به این پارتیشن Domain NC گفته شود.

 

Configuration Partition: شامل تنظیمات و ساختار منطقی و فیزیکی اکتیو دایرکتوری است. همانند سایت ها، دامین ها و Subnet ها که در بین تمام دامین کنترلر ها در جنگل Replicate می شود.

 

Schema Partition : این پارتیشن شامل تمام اشیائی است که می تواند در سراسر یک جنگل (Forest) ساخته شود، همچنین معین کننده نوع  مقادیر آن ها است. که در بین تمام دامین کنترلر ها در جنگل Replicate می شود.

 

* Replication به عمل یکسان ساری اطلاعات دامین کنترلرها  با هم دیگر گفته می شود.

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

 

در گذشته، تمام Replica ها در تمام دامین کنترلرها خواندنی – نوشتنی بود، اما با Read-only Domain Controller ها  قدری این تفکر را تغییر پیدا می کند. در RODC ها، یک نسخه فقط خواندنی از Replica نگه داری می شود. البته نکته قابل توجه آن است که اطلاعات حیاتی با RODC ها Replicate نمی شود همانند Password ها. هرچند که می توان می توان با استفاده از Password Policy در خصوص RODC ها این امکان را ایجاد کرد، اما به غیر از این مورد، موارد دیگری وجود دارند که هیچ گاه با دامین کنترلر های فقط خواندنی Replicate نمی شوند.

 

 

بررسی Global Catalog :

 

تصور کنید جنگلی شامل 2 دامین است و هر دامین شامل 2 دامین کنترلر است. بنابراین جنگل شامل 4 دامین کنترلر است. تمام این دامین کنترلر ها شامل Schema و Configurarion پارتیشن ها می شوند. دامین کنترلر هایی که در در دامین اولی هستند، Domain NC را بین خود Replicate می کنند و همین طور دامین دومی. اکنون اگر یک کاربر در دامین دوم یک کاربر در دامین اول را جستجو (Search) کند چه اتفاقی خواهد افتاد؟ از آنجایی که دامین کنترلرهای دامین دوم هیچ اطلاعاتی در خصوص Users دامین اول را شامل نمی شوند، به این شکل نمی توان جواب این Query را داد. اینجا است که Global Catalog پایش به میان می آید. GC هم یک پارتیشن است که اطلاعات تمام اشاء (Objects) را روی جنگل (Forest) شامل می شود. اما برای بازدهی بهتر، GC شامل تمام ویژگی های یک شیئ نیست ولی شامل بخشی از اطلاعات است که در جستجوی در اکتیو دایرکتوری مفید هستند. هرچند نادرست اما می توان تصور کرد که GC مشابه یک index برای AC است.

 

در گذشته قدری در اینجا با GC آشنا شدیم و وظایف مختلف آن را دیدم. همچنین دیدم که چگونه باید یک GC Server را تنظیم کنیم. به صورت ایده آل، تمام دامین کنترلرها GC Server هم هستند، اما شاید در همه جا چنین چیزی امکان پذیر نباشد. به عنوان یک قابلیت باید پذیرفت که شبکه ها با سرعتی قابل ملاحظه در حال دسترسی به این ایده آل هستند. در صورتی که یکی از شرایط زیر برقرار باشد توصیه می شود حتما در هر سایتی حداقل یک GC Server وجود داشته باشد:

 

1. لینک ارتباطی تا نزدیک ترین GC Server کم سرعت است یا اختلال زیادی دارد.

2. سایت شامل یک کامپیوتری است که Exchange Server را اجرا می کند.

3. نرم افزار های دیگری در سایت موجود است که از GC Server استفاده می کنند.

 

اگر دامینی تمام دامین کنترلرها GC باشند دیگر مدیریت operarion master ها اهمیت چندانی نخواند داشت. در جنگل های با یک دامین شاید چندان آنکه تمام دامین کنترلرها GC باشند کار سختی نباشد چرا که تمام دامین کنترلرها در واقع تمام ویژگی ها و اشیاء را شامل می شوند و در واقع بار اضافی برای سیستم و شبکه ندارد. اما در صورتی که جنگلی بیش از یک دامین داشته باشد، نیاز به مدیریت خاص در هر شرایط دارد و سرعت و کیفیت لینک ها و میزان ترافیک بین سایت ها پر اهمیت ترین فاکتور این مدیریت هستند.

 

بررسی Application Directory Partitions :

Application Directory Partition، پارتیشن محل ذخیره سازی اطلاعاتی است که مربوط به برنامه ها یا سرویس های غیر از سرویس اکتیو دایرکتوری است. برخلاف سایر پارتیشن ها می توان معین کرد که در بین کدام دامین کنترلر ها Replicate شود. هرچند به صورت پیش فرض بین تمام دامین کنترلرها Replicate می شود. این پارتیشن ها می تواند شامل هر نوعی شیئ باشد به غیر از اشیایی که به نحوی با امنیت مرتبط است همانند Users . از آنجایی که Replication این پارتیشن تحت ضوابط خاصی صورت می گیرد، نتایج خوبی در عملکرد و کنترل ترافیک دارد. راحت ترین مثال برای Application Directory Partition  می تواند Microsoft DNS Server باشد. وقتی که یک Zone یکپارچه با اکتیو دایرکتوری (Active Directory Intergrated Zone) ایجاد می کنید، رکورد های DNS توسط Application Directory Partition بین DNS Server ها Replicate می شود. توجه کنید که این اطلاعات بین تمام DC ها Replicate نمی شود.

 

 

این مطلب پیش زمینه ای برای مبحث Replication است که در آینده بحث خواهد شد

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

Operation Master در اکتیو دایرکتوری – قسمت اول

در اکتیو دایرکتوری تمام دامین کنترلر ها با همدیگر برابراند. آن ها می توانند اطلاعات را روی Database خودشان ذخیره نمایند و سپس آن را بین بقیه دامین کنترلرها Replicate  کنند . در اکتیو دایرکتوری دامین کنترلرهای Operaion Master فقط و فقط  Role های مشخصی را به عهده دارند و  با آنکه دامین کنترلر های دیگر می توانند آن ها را انجام دهند، از انجام دادن آن role ها سر باز می زنند.

 

تصور نکنید:اگر از مدیران شبکه قدیمی ویندوز NT هستید، لطفا تصور نکنید که operation master همان Primary Domain Controller است. همچنین می دانم تصور نخواهید کرد که این همان Read-Only Domain Controller است.

 

Operaion Master ها چی هستند؟

- اکتیو دایرکتوری شامل 5 رول Operation Master است. دوتای آنها در سراسر جنگل (Forest) انجام می شود آنها را Forest-wide می گوییم. توجه داشته باشد هر رول فقط توسط یک دامین کنترلر در سراسر جنگل صورت می پذیرد:

 

1. Domain Naming : در زمان اضافه یا حذف کردن یک دامین از این رول استفاده می شود. بنابراین در زمان اضافه کردن یا حذف کردن یک دامین در جنگل باید رول Domain Naming Master در دسترس باشد.

 

2. Schema : دامین کنترلری که رول Schema Master را دارد فقط  این دامین کنترلر می تواند تغییرات روی Schema در سراسر جنگل را اعمال کند. سایر دامین کنترلرها یک نسخه read-only از schema را نگه داری می کنند که آن را با دامین کنترلر که رول Schema Master دارد یکسان می کنند. اگر می خواهید Schema را تغییر دهید یا نرم افزاری نصب کنید که Schema را تغییر می دهد، توصیه می شود آن را در دامین کنترلری که رول Schema Master رادارد انجام دهید. در غیر این صورت تغییرات باید از Schema Master درخواست (Request) شوند.

 

- و سه تای آنها در هر دامینی انجام می شود. آنها را Domain-Wide می گوییم و توجه داشته باشید که فقط توسط یک دامین کنترلر در تمام دامین انجام می شود:

 

3.(Relative Identifier (RID : این رول بسیار حیاتی است. SID شناسه ای است که اشیاء همانند Users.Computers, Groups در سراسر یک دامین با آن شناسایی می شوند. SID یک عدد است که در سراسر دامین یکتا است. از آنجا که در هر دامین کنترلری می توان یک شیئ جدید ایجاد کرد، باید یک مکانیسمی وجود داشته باشد تا یکتا بودن SID آن را تضمین کند. RID Master بسیار شبیه به DHCP است حال آنکه به جای آنکه IP اختصاص دهد، از ID Pool خود، ID اختصاص می دهد.

 

4. Infrastructure : در یک جنگل که چند دامین دارد، اشیاء ترکیبی می توان ساخت. به عنوان مثال می توان گروهی را ساخت که شامل کاربرانی در دامین دیگر باشد! اگر کاربری که در دامین دیگر است move شد یا rename شد دامینی که شامل گروه است از کجا مطلع شود که کاربر تغییر کرده؟ infrastructure Master رولی است که اطلاعات دامین کنترلری که گروه در آن است را به روز می کند. برای راحتی نحوه عملکرد infrastructure فعلا تصور کنید که یک سیستم Tracking است و تغییراتی که روی اشاء دیگر اتفاق می افتد را ردیابی می کند.

 

5. PDC Emulator : این رول چند عمل حیاتی را در یک دامین انجام می دهد.

> ادای یک Primary Domain Controller را در می آورد! در گذشته، در زمان ویندوز NT 4.0 تغییرات روی اکتیو دایرکتوری فقط در PDC می توانست ذخیره شود. نرم افزارهایی که در آن زمان نوشته شده اند بر این اساس کار می کردند. اکنون روی هر دامین کنترلری می توان تغییرات را ذخیره و سپس با دامین کنترلرهای دیگر Replicate شود.  PDC Emulator هرچند واقعا یک PDC نیست اما وانمود می کند که PDC است! خود را به عنوان PDC در سراسر دامین معرفی می کند، هرچند که در روند نرم افزار های جدید تغییری به وجود نمی آید اما با نرم افزارهایی که برای روزگار PDC نوشته شده بودند هماهنگی ایجاد می کند. اکتیو دایرکتوری اکنون تقریبا 10 ساله شده است، بهتر است چنین نرم افزار های قدیمی به روز شوند. اگر امکان پذیر نیست با این رول می توانید سیستم عامل دامین کنترلرها را ارتفا دهید هر چند باید به Functional Level نیز توجه کنید.

 

> زمامی که  password یک کاربر reset می شود و یا Change می شود و… تغییراتی هستند که اهمیت بالایی دارند و نمی توان منتظر Replication ماند. بنابراین این دسته تغییرات به سرعتReplicate می شود. اما آیا بین تمام دامین کنترلرها Replicate می شود و آیا سرعت Replicate شدن کافی است؟ تغییرات به PDC Emulator گفته می شود. اگر یک کاربر بلافاصله پس از آنکه Password خود را تغییر داد Logon کند، ممکن است هنوز تغییرات به دامین کنترلری که در حال بررسی هویت کاربر است گفته نشده باشد بنابراین از password جدید کاربر بی اطلاع است. اما پیش از آنکه Username و Password را نپذیرد، سری به PDC Emulator می زند. در واقع درخواست Logon را به PDC Emulator می فرستد از آنجا که PDC Emulator همیشه آخرین تغییرات را می داند، کلمه عبور و نام کاربری کاربر را تایید می کند و به دامین کنترلر دستور می دهد تا logon را قبول کند. البته این به آن معنا است که هر زمانی که کاربر password خود را اشتباه وارد کند، درخواست Authentication به PDC Emulator ارسال می شود. بنابراین باید PDC Emulator سرعت ارتباطی بالا و امکانات سخت افزای قوی داشته باشد. (در خصوص وجود سایت بحث خواهد شد)

 

> اکتیو دایرکتوری، Kerberos ، FRS و بسیاری از سرویس های دیگر بسیار به قالب زمانی وابسته اند. پس همسان سازی ساعت و تاریخ (زمان) در تمام یک محیط بسیار پر اهمیت است. PDC Emulator ای که در Forest Root قرار دارد معین کننده زمان در تمام جنگل است. روند همسان سازی زمان به این صورت است که هر PDC Emulator زمان خود را با PDC Emulator موجود در Forest root همسان می کند و تمام دامین کنترلر های یک دامین خود را به PDC Emulator دامین خود. کلاینت ها و سرور های دیگر خود را با دامین کنترلرها همسان می کنند. این سلسه مراتب همسان سازی دامین در کاهش ترافیک و بار سرور ها خیلی موثر است و از طریق سرویس Win32time انجام می شود.

 

> زمانی که وارد Network می شوید. مثلا روی Start کلیک می کنید و Network را می زنید، لیستی از برخی کامپیوتر های موجود را می بینید. این لیست که Browse list نام دارد، توسط یک سرویس به نام Browser service ساخته می شود. Master Browser در شبکه های دامین وظیفه ساختن یک Browse List را دارد. یک PDC Emulator در نقش یک Domain Master Browser می تواند عمل کند.

 

همانطور که مشاهده کردید، سرویس های حیاتی وجود دارند که فقط روی یک دامین کنترلر قابل ارائه هستند. امروزه راهی برای ارائه شدن این سرویس ها روی چند دامین کنترلر وجود ندارد. امنیت، در دسترس بودن، امکانات سخت افزاری و سرعت مناسب ارتباط برای دامین کنترلرهایی که نقش های فوق را بر عهده دارند بسیار فاکتور های مهمی هستند. با توجه به آنکه در یک دامین یک دامین یا یک جنگل تنها یک دامین کنترلر می تواند این رول ها یا برخی از آنها را  به عهده داشته باشد،در یک جنگل با یک دامین 5 رول و در یک جنگل با 2 دامین 8 رول وجود دارد. این رول ها باید به خوبی مدیریت شوند.

 

 

جای مناسب Operation Master ها کجا است؟

 

زمانی که اولین دامین کنترلر در یک جنگل جدید و دامین چدید را ایجاد می کنید تمام 5 رول Operation Master بر عهده همان دامین کنترلر گذاشته می شود. بدیهی است که پس از آنکه دامین کنترلر دیگری اضافه کردید می توانید به علت Load Balance یکی یا چندی از این رول ها را به دامین کنترلر دیگری واگذار کنید. همچنین ممکن است با توجه به موقعیت فیزیکی، تصمیم بگیرید که رول ها را به دامین کنترلری که شرایط مناسب تری دارد منتقل کنید. بهترین نحوه این تنظیمات عبارت است از:

 

1. Schema Master و  Domain Naming Master باید روی یک دامین کنترلر که GC Server است قرار گیرد. این دامین کنترلر باید امن تر از دامین کنترلرهای دیگر باشد و از آنجا که این رول ها باهم و به GC وابسته اند بهتر است روی یک دامین کنترلر قرار گیرند.

2. RID و PDC Emulator روی یک دامین کنترلر باشند. اگر می خواهید که روی دو دامین کنترلر مختلف آن ها را تنظیم کنید، باید از لینک ارتباطی مطمئن و پر سرعتی بین این دو  دامین کنترلر موجود باشد. همچنین باید در Replication به صورت مستقیم باهم Repication انجام دهند. اما در هر حال بهترین حالت زمانی است که هر دوی آنها روی یک دامین کنترلر باشند مگر در شرایط خاص.

3. Infrastructure Master روی دامین کنترلر باشد که GC Server نیست اما از طریق یک لینک مطمئن و با سرعت مناسب به GC Server متصل است. مانعی برای قرار دادن Infrastructure Master روی همان دامین کنترلری که PDC Emulator و RID Master است وجود ندارد.

4. یکی از توصیه هایی که می شود آن است که تمام دامین کنترلرها GC Server باشند. در این صورت دیگر اهمیتی ندارد که کدام دامین کنترلر نقش Infrastructure Master را بازی کند.

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

6. یک برنامه برای failover یا redundancy ایجاد کردن داشته باشید. خواهید دید که می توان این رول ها را منتقل کرد. بدون شک باید این برنامه از پیش تعیین شده باشد.

 

این مطلب ادامه دارد…

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

Operation Master در اکتیو دایرکتوری – قسمت دوم

مشخص کردن Operation Master ها و انتقال آن ها:

برای تنظیم کردن یک دامین کنترلر در یک رول Operation Master، ابتدا باید بدانید که در حال حاضر کدام DC این رول را برعهده دارد. از طریق خط فرمان یا محیط گرافیکی می توان به مدیریت پرداخت:

 

الف. رول های Domain-Wide که عبارت اند از RID ، PDC Emulator و Intrastructure :  به کنسول Active Directory Users & Computers رفته  و سپس  روی دامین کلیک راست کرده و گزینه Master Operation را انتخاب کنید. در زبانه (tab) های مربوط به هر رول می توانید سروری که در حال حاضر آن رول را بر عهده دارد ببینید.

 

ب. رول Domain Naming : در کنسول Active Directory Domains and Trusts روی Root Node یعنی Active Directory Domains and Trusts کلیک راست کرده و گزینه Operaion Master را بزنید. حال می توانید سروری که در حال حاضر رول Domain Naming را بر عهده دارد مشاهده کنید.

 

ج. رول Schema Master : به MMC بروید. و از منوی File گزینه  Add/remove Snap-in را برنید. از لیست Snap-in های سمت چپ، Active Directory Schema را add کنید. سپس روی Root Node یعنی Active Directory Schema کلیک راست کنید و گزینه Operation Master را انتخاب کنید.

 

نکته مهم : باید Active Directory Schma Snap-in را در اولین باری که باز می کنید register کنید. در غیر این صورت در قسمت ج نخواهید توانست که Active Directory Schema را بین Snap-in های موجود پیدا کنید. برای این کار به خط فرمان رفته و سپس وارد کنید:

regsvr32 schmmgmt.dll

 

یادآوری: همانطور که پیش از این در قسمت یک گفته شده بود، زمانی که اولین دامین کنترلر در دامین جدید و جنگل جدید ایجاد می کنید آن دامین کنترلر تمام این 5 رول را بر عهده می گیرد. زمانی که اولین دامین کنترلر را در دامین جدید جنگل موجود ایجاد می کنید رول های Domain Wide را برعهده می گیرد. زمانی که دامین کنترلر های دیگری در دامین / جنگل ایجاد می کنید، توصیه می شود برای load Balance رول ها را بین دامین کنتر ها تقسیم کنید.

 

توجه مهم : اگر برنامه ریزی کرده اید که دامین کنترلر مدتی offline شود، اگر Master Operation روی آن دامین کنترلر است حتما آن ها را انتقال دهید.

 

برای انتقال Operation Master ها باید 3 گام کلی زیر را انجام دهید:

1. با توجه به آنچه در قسمت های الف تا ج گفته شد، به کنسول مربوط به role ای که می خواهید تغییر دهید بروید.

2. روی Root Node کلیک راست کنید و گزینه های Connect to Domain Controller یا Change Domain Controller را بزنید و به دامین کنترلری که می خواهید رول به آن منتقل شود را انتخاب و به آن متصل شوید.

3. مشابه آنچه در قسمت های الف تا ج گفته شد عمل کنید. سپس دکمه change را بزنید.

تذکر: در محیط عملیاتی برای یادگیری آزمایش نکنید. همچنین پیش از انتقال از صلاحیت  (فیزیکی -  منطقی) دامین کنترلر مقصد اطمینان یابید.

تذکر: بهتر است پس از انتقال یک Replication بین دو دامین کنترلر به صورت force انجام شود هر چند عدم انجام مانعی ندارد.

 

زمانی که یک role را منتقل می کنید و هر دو دامین کنترلر online هستند. یعنی در شبکه در حال سرویس دهی هستند. به سرعت دامین کنترلر جدید رول را بر عهده می گیرد و دامین کنترلر قدیمی از انجام role سر باز می زند. این روش بهترین روش انتقال این رول ها است.

 

خرابی دامین کنترلر های دارای یک وظیفه Operation Master و مصادره رول ها :

چنانچه دامین کنترلری که یک رول Operation Master را به عهده دارد، خراب شود و دیگر امیدی به رکاوری نباشد یا اینکه برای مدت زیادی زمان نگه داری نیاز داشته باشد، اگر نتوانسته بودید که رول ها را انتقال دهید می توانید آن ها را Seizing یا مصادره کنید. در خصوص هر کدام از این رول ها شرایط خاصی ایجاد خواهد شد:

 

1. PDC Emulator : این رول اگر در دسترس نباشد سریع تر از تمام رول های دیگر در شبکه ایجاد اختلال خواهد کرد و کاربران سریع با مسئله درگیر می شوند. خوشبختانه می توان این رول را Seize کرد و سپس به سرویس دهنده اصلی بازگرداند. منظور از سرویس دهنده اصلی دامین کنترلری است که وظیفه PDC Emulator را بر عهده داشته.

 

2. infrastructure Master : هرچند در خرابی های این role  شاید کاربران سریع درگیر نمی کند، اما مدیران را اذیت خواهد کرد. می توان این رول را Seize کرد و با بازگرداننده سرویس دهنده اصلی، رول را به او بازگردانند.

 

3. RID Master : خرابی RID Master باعث خواهد شد که دامین کنترلرها نتوانند SID جدیدی دریافت کنند. بنابراین از ساخت user,group و… جلوگیری به عمل خواهد آورد. از آنجایی که دامین کنترلر ها یک دسته SID را دریافت می کنند، ممکن است به سرعت با مشکل جدی رو به رو نشوید. Seize این رول عمل مناسبی نیست و توصیه نمی شود اما در صورت لزوم و اجتناب ناپذیر بودن آن، دامین کنترلری که این رول از آن مصادره شده است نمی تواند دوباره به کار خود بازگردد و online شود.

 

4. Schema Maste : این رول تنها زمانی حیاتی است که تغییر در Schema به وجود آید. حال چه توسط برنامه های Active Directory integrated چه توسط یک مدیر شبکه.  Seize این رول عمل مناسبی نیست و توصیه نمی شود اما در صورت لزوم و اجتناب ناپذیر بودن آن، دامین کنترلری که این رول از آن مصادره شده است نمی تواند دوباره به کار خود بازگردد و online شود.

 

5. Domain Naming Master : این رول زمانی کاربرد دارد که یک دامین به جنگل اضافه/حذف می شود.  Seize این رول عمل مناسبی نیست و توصیه نمی شود اما در صورت لزوم و اجتناب ناپذیر بودن آن، دامین کنترلری که این رول از آن مصادره شده است نمی تواند دوباره به کار خود بازگردد و online شود.

 

نحوه مصادره یک رول:

هشدار: در محیط عملیاتی برای یادگیری آزمایش نکنید. Seize عمل حساسی است.

 

با آنکه انتقال یک رول هم از طریق خط فرمان و هم از طریق محیط گرافیکی امکان پذیر است، مصادره کردن یک role فقط از طریق خط فرمان (CMD) امکان پذیر است. برای Seize کردن یک رول مراحل زیر را پیش بگیرد:

1. در run وارد کنید CMD و در خط فرمان وارد کنید ntdsutil و enter بزنید.

2.در فرمان ابزار ntdsutil وارد کنید roles و enter بزنید.

3. اکنون باید به دامین کنترلری که قرار اجرای role به آن واگذار شود، متصل شوید برای این کار در فرمان fsmo maintenance وارد کنید connections و enter بزنید.

4. اکنون در فرمان server connections وارد کنید connect to server DCFQDN و enter بزنید. دقت کنید DCFQDN نام کامل دامین کنترلر مورد نظر است مثلا : Server8.contoso.com

5.در فرمان Server connection وارد کنید quit و enter بزنید.

6.در فرمان fsmo maintenance وارد کنید seize ROLE و enter بزنید.

ROLE یکی از رول ها می تواند باشد یعنی : PDC , RID master , schema master , domain naming master , infrastructure master (خود لغت ROLE را وارد نکنید)

7.در فرمان fsmo maintenance و ntdsutil وارد کنید quit

* در هر مرحله می توانید از ؟ برای راهنمایی استفاده کنید.

** برای انتقال به جای دستور seize ROLE از دستور transfer ROLE استفاده کنید.

 

 

هشدار: به هیچ عنوان دامین کنترلر هایی که قابل بازگرداندن نیستند را به شبکه دوباره متصل نکنید. اگر می خواهید دوباره از آن استفاده کنید به استفاده از دستور dcpromo /forceremoval نقش دامین کنترلر را از آن حذف کنید. گاهی توصیه شده است از ابتدا ویندوز را روی آن نصب کنید و البته پس از این کار دوباره می توانند به دامین بازگردد، دامین کنترلر شود و رول(ها) را به آن انتقال داد. در هر حال مصادره کردن آخرین راه است.

پ.ن: اعتراف می کنم نمی دانم seize را  به فارسی چه ترجمه می کنند اما واژه های “مصاده یا توقیف” در اینجا مناسب ترین معنی لغوی است.

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

تنظیم DFS Replication برای SYSVOL در اکتیو دایرکتوری

همانطور که گفته شد؛ SYSVOL یک پوشه (folder) است که به صورت پیش فرض در systemroot%\SysVol% قرار دارد. این پوشه شامل اطلاعاتی نظیر Group Policy Templates است. در حالت ایدآل، فلدر های sysvol روی تمام دامین کنترلرها باید کاملا یکسان باشند. مدیران شبکه باید Replication فلدر sysvol را طوری مدیریت کنند که ضمن کافی بودن، بیشترین اثربخشی را داشته باشد. در گذشته  از File Replication Service یا به اختصار FRS برای Replication دو فلدر SysVol استفاده می شد اما از ویندوز سرور 2003 R2 به بعد، با توجه به مزایای DFS-R توصیه می شود از DFS-R استفاده کنید. تنظیم، مدیریت و حل مشکل FRS قدری دشوار است و از لحاظ حجم و performance دارای محدودیت است(به علت الگوریتم) بنابراین مهاجرت به DFS-R برای تمام شبکه ها توصیه می شود.

 

توجه: با توجه به مطلبی که در اینجا مطرح شده، Domain Functional Level را به ویندوز سرور 2008 باید ارتقاء دهید. صرفا استفاده از ویندوز سرور 2008 برای استفاده از DFS-R کافی نیست.

 

 

مراحل مهاجرت:

از آنجایی که SysVol شامل اطلاعات حیاتی برای دامین است، ویندوز فرآیندی برای انتقال یک دفعه ای از FRS به DFS-R ندارد. فرآیند مهاجرت به این شکل است که ابتدا یک ساختار موازی با SysVol ایجاد می شود و سپس Request های برای SysVol به ساختار جدید هدایت می شود. زمانی که مشخص شد مکانیسم DFS-R به خوبی کار می کند، FRS حذف می شود. این مهاجرت در 4 گام صورت می گیرد:

 

گام 0 ، شروع : زمانی است که فقط از FRS برای Replicate کردن SysVol استفاده می شود.

گام 1، آماده شده :  یک کپی از فلدر SysVol به نام SysVol_DFS ساخته شده و DFS شروع به Replicate کردن آزمایشی می کند. هر چند هنوز از فقط از پوشه SysVol استفاده می شود و با FRS عملیات Replication صورت می گیرد.

گام 2، هدایت شده : دیگر از فلدر SysVold_DFS استفاده می شود و نام Share پوشه Sysvol به  SysVold_DFS مسیرش عوض می شود.

گام3، حدف شدن: Relicate شدن با FRS متوقف می شود، هرچند پوشه SysVol همچنان موجود است و اگر می خواهید آن را delete کنید باید دستی این کار را انجام دهید.

 

نحوه مهاجرت:

روی خط فرمان (CMD) می توانید مهاجرت را آغاز کنید. این کار با دستور DFSRmig انجام می شود. از 3 سوییچ این دستور باید استفاده کنید:

 

SetGlobalState State :  با این سوییچ می توانید مرحله مهاجرت را تعیین کنید. متغییر state مقادیر 0 تا 3 را می تواند اختیار کند. (مشابه آنچه در مراحل گفته شد) تمامی دامین کنترلر ها از مهاجرت به مرحله دیگر مطلع می شوند و خود را منطبق می کنند.

 

GetGlobalState : با این سوییچ می توانید مرحله فعلی مهاجرت را ببینید.

 

GetMigrationSate : با این سوییچ می توانید وضعیت فعلی مهاجرت هر دامین کنترلر را ببینید. علت وجود چنین سوییچی آن است که مدت زمانی طول می کشد تا دامین کنترلرها از مرحله جدید مهاجرت آگاه شوند و از آن مهم تر مدت زمانی طول می کشد تا دامین کنترلر فعالیت های مربوط به مهاجرت را انجام دهد.

 

برای افزایش مرحله مهاجرت، از سوییچ SetGlobalState استفاده کنید و برای رفتن به مرحله بعدی باید 15 دقیقه تا 1 ساعت منتظر بمانید. در زمان انتظار حتما با سوییچ  GetGlobalState وضعیت کلی و با سوییچ GetMigrationState وضعیت هر دامین کنترلر را بررسی کنید.

 

دلایل مهاجرت و آشنایی با DFS-R :

استفاده از تکنولوژی های DFS مقاومت در برابر خطا افزایش یافته و در شبکه های WAN همسان سازی اطلاعات بهتر صورت گیرد. DFS کوتاه شده ی Distributed File System است که یکی از این تکنولوژی ها DFS Replication است. مزایای DFS-R عبارت اند از:

 

1. اثر بخشی بیشتر در استفاده از شبکه : فقط تغییراتی که روی یک فایل اتفاق افتاده منتقل می شود. استفاده از الگوریتم فشرده سازی بایتی جدید به نام Remote differential compression و …

2.مدیریت آسان تر : با استفاده از Snap-in به نام DFS Managment می توان آن را مدیریت کرد.

3. دسترسی آسان تر به اطلاعات با استفاده از مجازی سازی فضای نامی

4. توسعه های در مقیاس های بزرگ : از آنجایی که تنظیمات آن در اکتیو دایرکتوری ذخیره می شود، DFS-R یک متد Replication مطمئن است که بدون توجه به توپولوژی می توان هزاران node را پوشش دهد.

و…

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

Active Directory Lightweight Directory Service – قسمت اول

جمعه ۲۰ فوریهٔ ۲۰۰۹

سرویس Active Directory Lightweight Directory یا به اختصار AC LDS یکی از سرویس های 5 گانه مرتبط با تکنولوژی اکتیو دایرکتوری در ویندوز سرور 2008 است. در ویندوز سرور 2003 سرویسی مشابه AD LDS به نام  Active Directory Application Mode یا به اختصار ADAM موجود بود که اکنون AD LDS با برتری هایی که نسبت به ADAM دارد جایگزین شده است. همانطور که از اسم این سرویس مشخص است سرویسی کوچک شده از سرویس AD DS است که در واقع مهمترین وظیفه AD LDS پشتیبانی از نرم افزار هایی است که به سرویس دایرکتوری برای فعالیت خود نیازمند اند اما در شبکه بنا به دلایلی نصب AD DS را مناسب نمی دانیم و یا ترجیح می دهیم سرویس AD DS دست نخورده باقی بماند. یک مثال پرکاربرد، نرم افزار Microsoft Exchange Server 2007 است که تمام اطلاعات کاربران در این برنامه با سرویس دایرکتوری نگه داری می شود. زمانی که Microsoft Exchange Server 2007 را نصب می کنید، در AD DS Schema مواردی را اضافه می کند که تقریبا شاید حجم را به 2 برابر می رساند. تغییر روی Schema شاید کار جالبی نباشد چرا که این تغییر همیشگی است و غیرقابل حذف شدن است، هرچند می توان آن را غیر فعال کرد. از طرفی، روز به روز شاهد افزایش تعداد برنامه های Active Directory integrated (برنامه های یکپارچه با AD) هستیم که بسیاری از آنها Schema را ویرایش می کنند. با توجه به آنکه ممکن است نخواهید یک برنامه Schema را در محیط اکتیو دایرکتوری شما ویرایش کند، راهکار AD LDS بسیار راهکار خوبی است. البته در آینده در خصوص بهترین طراحی اکتیو دایرکتوری و سناریوهای مرتبط با هر کدام از سرویس های 5 گانه صحبت خواهم کرد.

 

در هر حال زمانی که قصد نصب یک نرم افزار که Schema را تغییر می دهد دارید باید با دقت کافی عمل کنید چرا که سرویس اکتیو دایرکتوری برای سالیان بسیاری در محیط کاری شما باقی می ماند. حتی با به روز شدن نسخ ویندوز سرور و سرویس اکتیو دایرکتوری، از مهاجرت به نسخه جدید تر ویندوز و یا Upgrade استفاده خواهید کرد بنابراین اگر تغییری در Schema ایجاد شود ممکن است تا بیش از یک دهه باقی بماند. حال ممکن است از نرم افزار اتوماسیون اداری استفاده می کنید که Schema را ویرایش می کند، با عوامل مختلفی ممکن است آن نرم افزار دیگر تولید نشود و یا در هر عوامل دیگری ایجاد شود که مجبور خواهید شد از نرم افزار دیگری استفاده کنید. همانند آنکه آن برنامه دیگر نیازهای سازمان شما را برآورده نمی کند و به استفاده از نرم افزار دیگری روی می آورید.  اکنون با توجه به آنکه تغییرات روی Schema قابل حذف نیستند، بسیاری از اطلاعات بیهوده نگه داری می شوند، زمان replication بالا می رود و … .

 

سرویس AD LDS می تواند تمام نیاز های یک نرم افزار یکپارچه با AD را بر آورده کند و سرویس AD DS دست نخورده باقی بماند.(در خصوص Global Catalog دقت کنید) به اضافه آنکه به اعتبارات گروهی Enterprise Administrator و Schema Administrator برای ویرایش AD LDS نیاز نیست و مدیران شبکه هر بخش می توانند خود به مدیریت بپردازند. مدیریت AD LDS آسان تر است و حتی نصب آن به Restart بی نیاز است. AD LDS مشابه AD DS از پروتکل Lightweight Directory Access Protocol یا LDAP استفاده می کند  و بنابراین یک ساختار سلسله مراتبی دارد. نکته قابل توجه دیگر آن است بر خلاف اکتیو دایرکتوری دامین سرویس، Directory Partition در AD LDS از نامگذاری پروتکلهای X500 پشتیبانی به عمل می آورد. AD LDS از Global Catalog و Trusts بهره نمی برد و فاقد Group Policy ، X509 و PKIs است. (Public key infrastructure) لزومی ندارد AD LDS روی یک دامین کنترلر Run شود و می تواند با ابزار Backup ویندوز سرور 2008 یکپارچه کار کند.

 

بهبود های AD LDS نسبت به ADAM :

1. امکان نصب در Server Core

2.امکان Auditing پیشرفته

3. پشتیبانی از سایت ها مشابه AD DS

4. پشتیبانی از ابزار Database Mounting Tool  یا در واقع Dsamain.exe که در ریکاوری بسیار مفید است.

و بسیاری دیگر

 

پیشنیاز های نصب AD LDS :

1. سیستم عامل مورد پشتیبانی همانند Windows Server 2008, Enterprise Edition
2. یک User Account با داشتن حقوق مدیریتی Local

پیشنیاز های حذف AD LDS :

1. حذف کردن تمام نرم افزارهای مرتبط از طریق Programs & Features از کنترل پنل
2. یک User Account با داشتن حقوق مدیریتی Local

 

نصب Active Directory Lightweight Directory Service :

به Server Manager بروید و در قسمت Roles گزینه Add Roles را بزنید. در ویزاردی که باز می شود Active Directory Lightweigh Directory Services را انتخاب کنید و سپس نصب را انجام دهید. اکنون باید مرحله دوم را انجام دهید. می توانید به Administrative Tools بروید و Active DActive Directory Lightweigh Directory Services Setup Wizard را بزنید. همچنین می توانید به پوشه (Folder) ویندوز رفته و سپس در آن پوشه adam رفته و adaminstall را بزنید. به عبارت دیگر به systemroot%\adam% بروید. راهنمای مراحل این ویزارد و نحوه تنطیمات AD LDS را در قسمت بعدی بررسی خواهیم کرد.

 

این مطلب ادامه دارد…

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

Active Directory Lightweight Directory Service – قسمت دوم

در قسمت قبل رول Active Directory Lightweight Directory Service را نصب کردیم و به مرحله انجام ویزارد نصب و تنظیمات اولیه رسیدیم، حال مطلب را ادامه می دهیم.

 

پیش نیاز ها:

نصب  AD LDS مشابه AD DS شامل دو مرحله است. مرحله اول نصب Role بود که در قسمت قبل انجام شد، مرحله دوم تنظیمات اولیه است که در اینجا بررسی می شوند:

 

آ. توصیه می شود یک پارتیشن یا والیوم به غیر از پارتیشنی که سیستم عامل روی آن قرار دارد را جهت نصب نمونه آماده کنید.

 

ب. یک نام که توصیه می شود یک نام با معنی انتخاب کنید.

 

پ. پورت ها، AD LDS و AD DS هر دو از پورت های یکسان برای انتقال اطلاعات استفاده می کنند (به صورت پیش فرض) این پورت ها شامل LDAP یا پورت 389 و LDAP Over SSL یا Secure LDAP پورت 636 است. به اضافه آنکه AD DS از دو پورت 3268 برای دسترسی به GC با پروتکل LDAP و پورت 3269 که برای دسترسی به GC با Secure LDAP استفاده می کند. بدیهی است از آنجایی که GC در AD LDS موجود نیست، این دو پورت بدون استفاده برای AD LDS هستند. این مسئله تداخل پورت ها دلیل خوبی برای آن است که روی یک سرور AD LDS و AD DS را با هم اجرا نکنیم هرچند که ویزارد می تواند به صورت خودکار این تداخل را تشخیص دهد و در این صورت پورت های 50،000 , 50،001 را به صورت پیش فرض انتخاب می کند و برای موارد اضافی نیز پورت هایی از همان Range انتخاب می کند. می توانید به دلایل خاص این پورت ها را تغییر دهید مثلا زمانی که در اشغال نرم افزار دیگری هستند و در غیر این صورت تغییر پورت ها توصیه نمی شود. اگر در یک محیط دامین این کار را انجام می دهید توصیه می شود پورت های 50،000 را انتخاب کنید.

 

ت. یک نام برای Active Directory Application Partition می توانید انتخاب کنید. این نام باید یک نام DN یا distinguished name باشد که به عنوان مثال به این شکل نوشته می شودCN=AppPartADLDS,DC=Contoso=DC=com . اینکه یک Application Partition ایجاد کنید یا خیر بستگی به نیاز محیط عملیاتی شما دارد. همانطور که می دانید App. Partition برای کنترل replication در یک سرویس دایرکتوری کاربرد دارد. به عنوان مثال زمانی که یک Active Directory Intergrated Zone در MS DNS ایجاد می کنید، از یک پارتیشن برای همسان سازی اطلاعات استفاده خواهد شد. یک App. Partition برای AD LDS هم برای کنترل ترافیک Replication کاربرد دارد. در سه روش می توان یک Application Partition مربوط به AD LDS ایجاد کرد. زمامی که سرویس را نصب می کنید. زمانی که نرم افزاری نصب می کنید که وابسته به سرویس است و یا به صورت دستی و با استفاده از دستور LDP.exe. توصیه می شود اگر نرم افزاری نصب می کنید که به صورت خودکار App. Partition نمی سازد در زمان نصب سرویس یک Application Partition بسازید.

 

ث. یک Account برای اجرای سرویس نیاز خواهید داشت. هرچند می توانید از اشتراک Network Service استفاده کنید اما در برخی سناریو ها مثلا زمانی که چندین نمونه را همزمان به کار می گیرید و یا مواردی که اعتبارات خاص نیاز است استفاده از Network Serivce ناکارآمد خواهد بود. برای ساخت یک Account دیگر اقدام کنید و توصیه های زیر را در نظر بگیرید:

 

- اگر در محیط اکتیو دایرکتوری هستید یک Domain Account بسازید و در غیر این صورت Local Account بسازید.

- نام Account با نام نمونه (Instance) یکی باشد.

- از یک پسورد بسیار ایمن استفاده کنید. (بسیار پیچیده باشد)

- گزینه های  User Cannot change Password و  The Passowd Never Expire را انتخاب کنید.

- در هر کامپیوتری که میزبان نمونه است (نمونه را روی آن می سازید) حق Logon as a Service را به Account بدهید. (از طریق Local Security Policy در صورت در دسترس بودن)

- برای Auditing حتما گزینه های مربوطه را تنظیم کنید.

 

ج. گروهی که مدیران AD LDS هستند. بهتر است همواره یک گروه را انتخاب کنید  حتی اگر آن گروه شامل یک کاربر باشد. بهتر است یک گروه هم نام با نمونه بسازید و اگر در دامین هستید، یک Domain Group و اگر نیستید یک Local Group  بسازید. خود را در آن گروه عضو کنید.

 

چ. فایل های LDIF یا Light Weight Directory Interchange Format که سبب توانایی هایی برای AD LDS علاوه بر توانایی ها پیش فرض می شود. این فایل ها در systemroot%\Adam% قرار می گیرند. به عنوان مثال برای هماهنگ شدن AD DS با AD LDS باید فایل ms-AdamSyncMetaData.ldif را انتخاب کنید. می توانید فایل های جدیدی اضافه کنید اما فایل های موجود به شرح زیر اند:

 

-  فایل ms-ADAM-upgrade-1.ldf : به روز رسانی Schema به آخرین ورژن موجود.

- فایل ms-ADAMSchemaw2k3.ldf : برای همکاری با اکتیو دایرکتوری در ویندوز سرور 2003 پیش نیاز و لازم است.

- فایل ms-ADAMSchemaw2k8.ldf : برای همکاری با اکتیو دایرکتوری در ویندوز سرور 2008 پیش نیاز و لازم است.

- فایل ms-ADAMSyncMetadata.ldf : برای همکاری با یک جنگل AD DS با AD LDS پیش نیاز و لازم است.

- فایل ms-ADLDS-DisplaySpecifiers.ldf : برای استفاده از کنسول Active Directory Sites & Services  در AD LDS لازم است.

- فایل ms-InetOrgperson.ldf : برای ساختن کلاس های InetOrgPreson User لازم است.

- فایل ms-User.ldf : برای ساخت کلاس های کاربری (User Classes) لازم است.

- فایل ms-UserProxy.ldf : برای ساختن کلاس ساده ی UserProxy لازم است.

- فایل ms-UserProxyFull.ldf : برای ساختن کلاس کامل UserProxy لازم است. ms-UserProxy.ldf یا ms-inetOrgPerson.ldf نیز در صورت انتخاب این گزینه باید انتخاب شوند.

 

 

شروع به تنظیمات:

1. ویزارد AD LDS Setup Wizard را مطابق آنچه پیش از این توضیح داده شد اجرا کنید و Welcome ویزارد را بخوانید و Next بزنید.

2. در گام بعدی در خصوص آنکه آیا یک نمونه (instance) جدید ایجاد شود یا یک Replica از یک instance موجود ایجاد شود سوال می شود. دقت داشته باشید که اگر یک New instance ایجاد کنید (یعنی A unique instance را انتخاب کنید) ، نمونه جدید نمی تواند با نمونه های گذشته Replication انجام دهد. اگر می خواهید که یک Replica از یک نمونه ی AD LDS موجود ایجاد کنید، گزینه A Replica of an existing instance را انتخاب کنید. من فعلا گزینه اول را انتخاب می کنم. با زدن Next به مرحله بعدی Wizard بروید.

3. در این مرحله باید یک نام برای نمونه جدید انتخاب کنید.

4.  در مرحله بعدی باید با توجه به آنچه در بخش پیش نیاز ها گفته شد، پورت ها را انتخاب کنید. با زدن Next به مرحله بعدی می رویم.

5. در این مرحله باید معین کنیم که آیا App. Partition ساخته شود یا خیر، با توجه به آنچه در پیش نیاز ها گفته شد.

6. در این مرحله باید محل قرار گیری فایل های سرویس دایرکتوری را معین کنیم که به صورت پیش فرض در مسیری مشابه C:\Program Files\Microsoft ADAM\InsanceName\Data ذخیره می شود. InstanceName نام نمونه است و به توصیه پیش نیاز توجه کنید. با زدن Next به مرحله بعدی می رویم.

7. اکنون باید Account مناسب را با توجه به مباحث پیش نیاز معین کنیم.

8. در مرحله بعدی باید مدیر (ها) سرویس AD LDS را معین کنیم. توصیه می شود یک گروه را انتخاب کنید.

9. حال باید فایل LDIF را برای Import شدن انتخاب کنیم.

10. با زدن Next فرآیند نصب را تایید می کنیم و نصب شدن آغاز می شود. به Restart شدن نیازی نیست.

 

این مطلب ادامه دارد…

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

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

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

 

اگر در Branch Office دامین کنترلری موجود نباشد بدون شک باید عملیات Authenticate از طریق لینک WAN و توسط دامین کنترلری که در Main Office موجود است انجام شود. حال در آغاز ساعت کاری که تمام کارمندان می خواهند Login کنند، با دو مشکل رو به رو خواهیم شد. یکی کمبود پهنای باند WAN و دیگری ترافیک بالای دامین کنترلر ها در Main Office. مسئله دیگر Service Ticket ها است که یکی از اجزای جدید Kerberos در ویندوز سرور 2008 است. فعلا هر چند نادرست اما تصور کنید مشابه یک کلیدی است که برای استفاده از سرویس ها توسط دامین کنترلرها برای کاربران صادر می شود و از آنجایی که در هر روز معمولا چندین بار این اتفاق برای هر کاربر می افتد، اگر در دفتر شعب دامین کنترلر نباشد باید از طریق لینک WAN و از دامین کنترلر موجود در Main Office صادر شود. این مسائل و مسائل مشابه دیگری ما را مجبور می سازد تا در هر Branch Office یک دامین کنترلر قرار دهیم و آن را به عنوان یک سایت معین کنیم. همچنین هر شعبه یک IP Subnet مخصوص خود خواهد داشت. اما با توجه به محدودیتی هایی که در ابتدا اشاره شد نمی توان یک دامین کنترلر را در شعب قرار داد چرا که اگر دامین کنترلر مورد هر نوع تهاجمی قرار گیرد، امنیت در تمام شبکه به مخاطره می افتد لذا از یک RODC استفاده می کنیم.

 

به غیر از کلمه ی عبور User Accounts یک RODC تمام اطلاعاتی که روی یک دامین کنترلر است را نگه داری می کند اما کلاینت ها نمی توانند تغییراتی روی RODC ذخیره کنند. برخی نرم افزاری هایی که از AD DS برای ذخیره سازی اطلاعات خود استفاده می کنند ممکن است اطلاعات پر اهمیتی همانند کلمه عبور یا کلید های Encryption را ذخیره کنند که نباید در RODC ها ذخیره شود. در این خصوص هم می توانید معین کنید این اطلاعات پر اهمیت در RODC ها ذخیره نشوند. زمانی که کاربر می خواهد Login کند، RODC درخواست را دریافت می کند و آن را برای DC موجود در Main Office می فرستد. DC عملیات Authentication را انجام می دهد. اگر قابلیت Cache کردن در RODC فعال باشد، RODC اطلاعات را Cache می کند و اگر دفعه بعدی کاربر بخواهد Login کند، RODC خود جواب Authentication را می دهد. از آنجایی که RODC فقط اطلاعات یک زیر مجموعه ای از کاربران را Cache می کند، تهدید آنکه RODC مورد حمله قرار گیرد محدود می شود. DC های نوشتنی هم لیستی از اطلاعاتی که توسط دامین کنترلرها فقط خواندنی Cache شده را نگه داری می کنند. از آنجایی که Replication فقط یک طرفه صورت می گیرد، هیچ خطری نمی تواند شبکه را تهدید کند و تنها کافی است امنیت برای همان اطلاعات Cache شده بازسازی شود مثلا Password های همان عده از کاربران تغییر پیدا کند. بر خلاف DC ها RODC ها یک گروه Administrator به صورت Local دارند و می توانید به یک یا چند نفر از پرسنل Branch Office قابلیت مدیریت کردن را بدهید بدون آنکه عضو گروه Domain Admins باشند می توانند به نگه داری از RODC بپردازند و دیگر نگران فعالیت های آنان نخواهید بود. این چنین دیگر لازم نیست ساعات زیادی از وقت خود را صرف انتخاب permission های مناسب در بخش های Security کنسول های مختلف کنید.

 

 

نصب یک RODC :

برای نصب یک RODC مراحل زیر را طی کنید:

1. اطمینان پیدا کنید که Forest Functional Level حداقل Windows Server 2003 است. (اینجا و اینجا را بخوانید)

2. اگر در سراسر جنگل دامین کنترلری ویندوز سرور 2003 دارد adprep /rodcprep را اجرا کنید.

3. اطمینان پیدا کنید حداقل یک DC ویندوز سرور 2008 دارد.

4. نصب RODC

 

 

اگر یک Forest موجود را به روز رسانی می کنید تا شامل دامین کنترلر های ویندوز سرور 2008 باشد و قصد نصب RODC را دارید باید دستور adprep /rodcprep را اجرا کنید. این دستور باعث می شود تا مجوز های لازم جهت Replicate شدن Application Partition مربوط به DNS با RODC را ایجاد می کند. اگر تمامی دامین کنترلرها ویندوز سرور 2008 دارند نیازی به اجرای این دستور نیست. فایل ها مربوطه در دی وی دی ویندوز سرور 2008 در پوشه Sources در پوشه Adprep قرار دارد و این پوشه را در دامین کنترلری که رول Schema Master را دارد کپی کنید و در CMD به محلی که فایل ها را کپی کرده اید بروید و سپس دستور را اجرا کنید. توجه داشته باشید که برای اجرای این دستور باید مجوز های مدیریتی لازم را داشته باشید در واقع باید عضو گروه Enterprise Admins باشید چرا که قرار است Schema تغییر کند.

 

حداقل باید یک DC با ویندوز سرور 2008 وجود داشته باشد (در دامین) به صورت ایده آل این دامین کنترلر باید در نزدیک ترین سایت با به عبارت دیگر با کوتاه ترین لینک از محل قرار گیری RODC باشد. اگر می خواهید که RODC به عنوان DNS Server نیز عمل کند باید دامین کنترلر ویندوز سرور 2008 نیز شامل Zone های مربوطه باشد. نصب RODC مشابه نصب Additional Domain Controller است با این تفاوت که در انجام مراحل ویزارد باید چک باکس Read-Only Domain Controller را چک بزنید.

 

 

Read-Only DNS :

می توانید DNS Server را روی یک RODC نصب کنید و در این صورت کلاینت ها می توانند با ارسال Query به RODC که در واقع یک DNS Server است نام یا آی پی Resolve کنند. اما DNS Server ای که روی RODC است نمی تواند رکورد جدیدی روی آن ثبت شود. زمانی که کلاینت سعی می کند با استفاده از DDNS یک Record را به روز کند، DNS Server روی read-only Domain Controller کلاینت را ارجاع می دهد و کلاینت رکورد را در محلی که DNS Server روی RODC ارجاع داده Update می کند. البته در پشت صحنه مسائل پیچیده تری از آنچه گفته شد اتفاق می افتد که در آینده بیشتر بررسی خواهند شد.

 

سناریوهای دیگر:

هرچند که در به سناریو ی محدودیت ها اشاره کردیم اما ممکن است به دلایل دیگری نیز استفاده از Read-Only Domain Controller ها لازم باشد. همانند سناریو هایی که یک نرم افزار LOB یا Line Of Bussines روی دامین کنترلر ها اجرا می شود. برای مدیریت LOB ها می توان به صورت Interactive یا در واقع از پشت کامپیوتر Login کرد و یا از Terminal Service استفاده کرد. با استفاده از RODC در آینده این شانس وجود دارد تا بتوان افرادی به غیر از گروه Admins بتوانند به صورت Interactive به سیستم وارد شوند و هیچ تهدید امنیتی وجود نداشته باشد. احتمال می رود در آینده با حل مشکلات موجود RODC نحوه طراحی تغییر یابد و شاهد بهبود های بسیاری باشیم. تصویر زیر مثالی از این تغییر طراحی است.

 

 

این مطلب در آینده با مطالب مرتبط دیگری تکمیل می شود.

PKIs و AD CS – قسمت اول

 

 

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

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


 

فرض کنید روشی وجود دارد که تقریبا یک طرفه باشد، به این معنی که رمزنگاری اطلاعات آسان است اما رمزگشایی آن دشوار، بنابراین همه می توانند اطلاعات را رمزنگاری کنند اما نمی توانند آن را رمزگشایی کنند. دو کلید مختلف در دسترس است یک کلید برای رمزنگاری اطلاعات و دیگری برای رمزگشایی. رسیدن به کلید رمز گشایی از طریق کلید رمزنگاری تفریبا غیرممکن است یا اگر بخواهیم بهتر بگوییم، باید بگوییم دشوار است. حال در پایتخت که شما در آن حضور دارید، دو کلید مخصوص به خود دارید که عبارت اند از کلید CEK و CDK (کوتاه شده ی Capital Encryption Key و Capital Decryption Key که البته دو واژه ای است که خودم آن ها را ساختم) با کلید CEK می توان اطلاعات را قفل کرد یا رمزنگاری کرد و با کلید CDK می توان قفل را باز کرد یا رمز گشایی کرد. به عبارت دیگر قفلی در اختیار دارید که با یک کلید فقط قفل می شود و با یک کلید دیگر فقط باز می شود. شما کلید CEK را در اختیار تمامی شهرداران قرار می دهید. حال هر زمان که شهرداری می خواهد به شما پیغامی ارسال کند آن را با CEK که خاص شما و پایتخت است رمزنگاری می کند اما نمی تواند آن را رمزگشایی کند چرا که CDK را ندارد و همچنین شهرداران دیگر هم چون فقط CEK را دارند و به CDK دسترسی ندارند نمی توانند اطلاعات را به دست آورند. با استفاده از همین مکانیسم می توان کلید های متعددی درست کرد و تمامی شهر ها دو کلید رمزنگاری و رمزگشایی مخصوص خود را داشته باشند. اکنون کلید های رمزنگاری را در دسترس همدیگر قرار می دهیم تا هر کسی، با هر کس دیگری که خواست بتواند ارتباط رمزنگاری شده داشته باشد اما فقط کسی که پیغام برای او صادر شده می توانند اطلاعات را رمزگشایی کند، دقت کنید که حتی خود نویسنده ی پیام هم نمی تواند اطلاعات را رمزگشایی کند با آنکه از محتوای پیام آگاه باشد. حال برای اطمینان بیشتر شما می خواهید کلید های خود را عوض کنید، با مشکل خاصی رو به رو نیستید فقط کافی است دو کلید جدید بسازید و کلید رمزنگاری خود را در اختیار همه قرار دهید. البته ممکن است که کلید رمزنگاری شما توسط حریف دزدیده شود و حریف اطلاعات تقلبی برای شما ارسال کند که با ترکیب این مکانیسم با مکانیسم های تشخیص هویت می توان صحت ارسال کننده را نیز علاوه بر صحت دریافت تایید کرد. به عبارت دیگر در این روش هیچ اهمیتی ندارد که اطلاعات شما به  دست حریف می افتد یا خیر تنها نکته مهم آن است که اطلاعات در زمان مناسب به شهر محاصره شده برسد. برای این کار شاید چند شوالیه زیرک داشته باشید که بتوانند خط محاصره را در هم بشکنند و پیغام را برسانند، شما یک نسخه از پیغام را به تمام آن شوالیه ها می دهید تا اگر چند نفر از آنها کشته یا اسیر شدند باز هم نسخه ای وجود داشته باشد که به دست شهردار برسد. به کلید رمزنگاری که در دسترس همگان است، کلید عمومی و به کلید رمزگشایی که امیدواریم فقط یک نفر داشته باشد کلید خصوصی می گوییم.

همانطور که دیدید در مکانیسم کلید عمومی/ کلید خصوصی مشکل قابل توجهی وجود دارد و آن پیام های جعلی است. تصور کنید حریف برای شهردار پیام جعلی ارسال کند که این پیام از طرف پادشاه یعنی شما صادر شده و دستور می دهد که تسلیم شوند و شهر را در اختیار حریف قرار دهند. از آنجا که حریف از مکانیسم رمزنگاری شما آگاه است و کلید عمومی را دارد، با کلید عمومی اطلاعات را رمزنگاری می کند و آن را برای شهردار ارسال می کند. حال باید مکانسیمی پیدا کنیم که با استفاده از الگوریتم موجود راه حلی ارائه شود. فرض کنید اسم خودتان را یعنی پادشاه به صورت یک متن رمزنگاری شده است، توجه کنید که تصور می کنیم متنی به رمز در آمده و حاصل “پادشاه” است، اکنون با استفاده از کلید رمز گشایی که کلیدی است که فقط خودتان آن را در اختیار دارید، آن را رمزگشایی می کنید بدیهی است که احتمالا نتیجه، متن دارای مفهومی نیست چرا که پادشاه داری مفهوم بود. حال این متن بی مفهوم را در پایان نامه خود اضافه کنید. دیگر لازم نیست که نامه را امضا کنید و آن را مهر بزنید چرا که این همان امضای شما است. به این امضا ما، فعلا امضای دیجیتال می گوییم. تمام متن را با استفاده از کلید رمزنگاری شهرداری که شهرش در حال محاصره است رمزنگاری کنید و توسط شوالیه ها ارسال کنید. وقتی شهردار پیغام را دریافت می کند با استفاده از کلید رمزگشایی خود که فقط خودش به آن دسترسی دارد می تواند متن را رمزگشایی کند و آن را بخواند. تمام متن خوانا خواهد بود به غیر از امضای شما، شهردار می تواند با استفاده از کلید رمزنگاری شما، متن امضای شما را (با استفاده از CEK ) رمزنگاری کند و به عبارت پادشاه، که یک عبارت با مفهوم است، برسد. حال اطمینان دارم شما پادشاه باهوش متوجه شدید که تنها کسی که می تواند متنی را تولید کند که در هنگام رمزنگاری اسم شما شود، فقط خود شما هستید، چرا؟ باید جمله گذشته را اصلاح کنیم، در واقع این بار با کلید خصوصی شما رمزنگاری می کنید و با کلید عمومی رمزگشایی می کنید چرا که باید فقط یک نفر بتواند بنویسد پادشاه اما همه باید بخوانند پادشاه.

همواره با استفاده از کلید عمومی رمزنگاری می کردیم، اما این بار برای آنکه کلید خصوصی تنها در دست یک فرد است و قصد داریم از هویت آن فرد آگاه شویم، با استفاده از کلید خصوصی رمزنگاری می کنیم، هرچند در مکانیسم بدون امضا کاربرد کلید خصوصی، رمزگشایی بود اما در این مکانیسم دیدم که کلیدها مهره هایی هستند که می توانیم با آنها بازی کنیم و مکانیسم های جدیدی بسازیم. اما همچنان شما پادشاه باهوش ایراد جالبی بر این روش می گیرید، به نظر شما ایراد کجاست و با چه بازی با این مهره ها می توان مشکل را حل کرد؟ اگر پیش از آنکه حدس زده باشید پاراگراف بعدی را بخوانید شما از حریف شکست خورده اید!!!

پیام شما به شهردار چنین چیزی بود:

“ به نام خدایان

ما سپیده دم حمله می کنیم شما در سپیده دم دروازه اصلی را باز کنید و حمله کنید تا خط محاصره شکسته شود.

شاینسشمیتسشکتیسهباهبسیبمیسمتبیستنبیسن”

این متنی است که شما نوشته اید و هنوز با کلید رمزنگاری شهردار آن را رمز نکرده اید. آن متن مسخره ی انتها هم امضای شما است. حال حریف (واسطه یا the man in the middle) یکی از نامه هایی که توسط شوالیه ها ارسال شده را به دست می آورد. پیامی که او می تواند بخواند، چنین است:

“ستیمنشتینششنیشتسیسش

نسشتیمنتسشیسشتیسشخیسشخیداسشایدشتایشیتسشیشسیهسشتیمهسشتیهسشتیشستیسشتیمسشتیمهصتشسشتدیتشسدی

شاینسشمیتسشکتیسهباهبسیبمیسمتبیستنبیسن”

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

پایان

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

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

در تمام سازمان های مدرن Public Key Infrastructures یا PKIs یکی از اجزای اصلی زیرساخت شبکه است. تقریبا به طریقی در هر سازمانی از یک Public Key (کلید عمومی) استفاده شده. مثلا در امنیت شبکه ی بیسیم یا VPN یا برای امنیت یک وب سایت. در واقع در دنیای امروز با نگاه کردن به هر گوشه ای می توان به خوبی Public Key ها را دید. امروزه کمتر سازمانی است که به بهبود های امنیتی بی نیاز باشد یکی از بهترین راهکارها در اکثر سناریو ها استفاده از Certificate ها است. یک PKI (زیرساخت کلید عمومی) ترکیبی از تکنولوژی رمزنگاری (Encryption) با چند سرویس و برنامه است که برای امن تر کردن ارتباطات خاص به کار می رود. از PKI می توان در موارد زیر بهره جست:

1. افزایش قابلیت اطمینان: می توان از زیرساخت های کلید عمومی برای امن تر کردن اطلاعات در وضعیت انتقال یا نگه داری استفاده کرد.

2. حفظ صحت و تمامیت اطلاعات : می توان از  PKI در Digital Sign استفاده کرد و با این روش مشخص می شود آیا واسطه ای اطلاعات را ویرایش کرده یا اطلاعات دست نخورده است. (The man in the middle)

3.تصدیق: زیرساخت کلید عمومی مکانیسم های متعددی جهت تعیین هویت دارد. به عنوان مثال پروتکل فرآیند authenticate شدن با پروتکل hash، همانند (Secure Hash Algorithm 1 (SHA1

4. عدم انکار : ارسال كننده‌ی پيام نميتواند ارسال پيام را انكار كند به دليل اينكه امضای او همراه نامه است.

 

به عنوان یک مثال ساده وقتی با استفاده از پروتکل Secure Hypertext Transfer Protocol یا Https وب سایتی را مشاهده می کنید یک گواهی نامه SSL در پشت صحنه وجود دارد، این گواهی نامه در واقع سندی است بر آنکه شما دقیقا روی همان وب سایتی که باید باشید هستید. زمانی که این گواهی نامه باز بینی شود می توان اطلاعاتی مثل Server Name و مرجع صادر کننده ی مجوز را مورد بررسی قرار داد. به مثال دیگری توجه کنید، سازمان A، با سازمان B روابط اقتصادی خوبی دارد و اطلاعات محرمانه ای بین این دو سازمان رد و بدل می شود. معمولا این اطلاعات به سادگی با یک ایمیل منتقل می شوند. بدیهی است که افرادی که این کلیت را بدانند می توانند با استفاده از اطلاعات تقلبی مشکل ساز باشند. بنابراین نیاز است تا اطمینان داشته حاصل شود که اطلاعات صحیح و سالم و از طرف سازمان دیگر به سازمان اول ارسال شده.

دو الگوریتم مختلف برای رمزنگاری وجود دارد، روش متقارن (Symmetric) و روش غیر متقارن  (asymmetric). در روش متقارن تنها از یک کلید استفاده می شود و مسئله حفظ امنیت کلید، فاش شدن الگوریتم، امکان پیام های تقلبی و… را حاصل می شود البته این به معنی نامناسب بودن این روش نیست هرکدام از این دو روش کاربرد های خاص خود را دارند و در شرایط مختلف راهکارهای مختلفی اندیشیده می شود. کلیدها چیزی غیر از صفر و یک نیستند. سیستم رمزنگاری مبتنی بر PKIs از دو کلید استفاده می کند. همانطور که دیدید یک کلید کلید عمومی است که برای همگان قابل دسترس می تواند باشد و کلید دیگر کلید خصوصی است که فقط در اختیار شخص دارنده است. البته امنیت هر دوی این کلید ها نیز باید حفظ شود. هرچند گاهی لازم است کلید عمومی واقعا در دسترس همگان باشد اما در اکثر سناریوها می توان دسترسی به کلید را محدود کرد هرچند اگر دسترسی غیرمجاز به کلید صورت گیرد جای هیچ ترسی وجود ندارد چرا که از روش های امنیتی پیچیده ای استفاده کرده ایم. به صورت کلی وقتی نیازی به دسترسی به کلید وجود ندارد، شما چرا آن را در اختیار دیگران قرار دهید. فرض کنید منزل خود را عوض کرده اید، با اینکه دیگر نمی توان با کلید های منزل قبلی وارد منزل جدید شد، چه دلیلی وجود دارد که کلید های منزل قبلی را به دشمن خود تحویل دهید؟ زمانی که اطلاعاتی با استفاده از کلید عمومی رمزنگاری می شوند، فقط شخصی می تواند اطلاعات را رمزگشایی کند که کلید جفت آن کلید عمومی را داشته باشد به عبارت دیگر باید یک کلید خصوصی داشته باشد تا بتواند اطلاعات را رمزگشایی کند. به هر دو کلید عمومی و کلید خصوصی، جفت کلید می گوییم. در رمزنگاری متقارن، از آنجا که یک کلید بیشتر در اختیار نداریم، آن کلید را باید به مقصد از طریق یک کانال امن ارتباطی ارسال کنیم. از آنجایی که تمامی مقصد ها و مبداء دارای این کلید هستند به این کلید Shared Key یا کلید به اشتراک گذاشته شده می گوییم.

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

الگورتیم هایی وجود دارد که آنها را Message Digest و یا Hash می گوییم. الگوریتم های hash الگوریتم هایی هستند که اطلاعات را به صورت نامفهوم تبدیل می کنند.گروهی از این الگوریتم ها فقط یکطرفه هستند به این الگوریتم های One-way hash algoritms. از لحاظ ریاضی احتمال آنکه بتوان از عبارت نا مفهوم به عبارت مفهوم رسید بسیار کم است و از لحاظ کامپیوتری زمان آنکه بتوان از عبارت نا مفهوم به عبارت مفهوم رسید بسیار زیاد است (معمولا چندین قرن) با این روش امضا های متفاوتی با اطلاعات ارسال خواهد شد با اینکه محتوا یکسان است. ممکن است جفت کلیدی که برای امضا ها استفاده می شود با جفت کلیدی که برای رمزنگاری اطلاعات استفاده شود متفاوت باشد. این امر دو مزیت دارد؛ اول آنکه معمولا عمر کلید امضا ها بیشتر می شود و دوم انکه امنیت محکم تر می شود. یک مثال ساده در خصوص الگوریتم های یک طرفه و دو طرفه می تواند توابع Y=X+2 و Z=X^2 باشد. در تابع y با داشتن خروجی 4 می توان به ورودی 2 پی برد در حالی که در تابع z نمی توان منحصرا یک ورودی را پیدا کرد. البته بدیهی است که الگوریتم های hash بسیار پیچیده تر از این هستند. در اینجا متذکر که می شوم که امنیت نسبی است.

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

AD CS – قسمت دوم

 

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

 

 

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

همانند گواهینامه که هویت شما و آنکه مجوز رانندگی با چه وسایلی را دارید را شامل می شود، Digital Certificate ها هم شامل اطلاعاتی است نظیر:

1. هویت شما با آن اطلاعات مشخص شود.

2. هویت مرجع صادر کننده مشخص شود.

3. اطلاعاتی که بتوان از طریق آن با مرجع صادر کننده تماس گرفت.

همچنین کیفیت این مجوز بیشتر می شود اگر:

1. مرجع صدور بتواند آن را در هر زمانی که لازم باشد، باطل کند.

2. با رشوه دادن قابل اخذ نباشد و جعل کردن آن دشوار باشد.

3. ابطال شدن آن را بتوان از طریق ارتباط با مرجع صادر کننده  به سرعت متوجه شد.

 

استفاده از Digital Certificate ها سه هدف اصلی به دنبال دارد:

 

1. تصدیق هویت: برخی از راه هایی که Digital Certificate ها در تصدیق هویت به کمک می آیند، عبارت اند از:

آ. IPSec ، Internet Protocol Security

ب. Login کردن به کامپیوتر و تصدیق هویت کاربرد

پ. تصدیق هویت سرور برای کاربر با استفاده از Transport Layer Security ، TLS

ت. تصدیق هویت کلاینت در شبکه بی سیم

و بسیاری دیگر…

 

2. رمزنگاری : برخی از راه هایی که Digital Certificate ها در رمزنگاری به کمک می آیند، عبارت اند از:

آ. Secure Multipurpose Internet Mail Extensions ، S/MIME

ب. TLS

پ. Encryption File System ، EFS

 

3. صحت داده ها : رمزنگاری در انتقال اطلاعات و امضای دیجیتال که در قسمت قبل بحث شد.

 

کلاس ها:

شرکت VeriSign کلاس بندی برای Certificate ها کرده است که از این قرار است:

 

کلاس 1 : برای اشخاص حقیقی

کلاس 2: برای اشخاص حقوقی

کلاس 3: برای نرم افزار ها و سرو ها

کلاس 4: برای تراکنش های آنلاین مالی بین شرکت ها

کلاس 5: برا ی سازمان های سری و سازمان های امنیتی و سری دولتی

 

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

 

Certificate Service چیست؟

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

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

1. Manual verification  : که به صورت دستی مدیر صدور مجوز درخواست شده را تایید می کند.
2. Automatic approval : که بر اساس عضویت در Active Directory Domain Service صورت می گیرد.

 

 

شروع با Active Directory Certificate Services :

Active Directiry Certificate Services با زیرساخت Public Key و Certificate در سناریو های مختلفی کاربرد دارد از جمله:

 

1. رمزنگاری فایل ها. یکی از بزرگترین مشکلات امنیتی امروز، به سرقت رفتن اطلاعات روی کامپیوتر های قابل حمل است. با ویندوز سرور 2008 و در ویندوز ویستا یا سون می توانید با استفاده از Group Policy تمام اطلاعات کاربران را رمزنگاری کنید.

2. رمزنگاری ارتباطات. ویندوز سرور 2008 شامل هر دو پروتکل IPSec و Secure Sockets Tunnelling Protocol یا SSTP است. هر دوی این پروتکل ها به زیرساخت Certificate ها در مبدا و مقصد وابسته اند.

3. امنیت Email ها: ویندوز سرور 2008 شامل پروتکل Secure Multipurpose Internet Mail Exchanges یا S/MIME است. این پروتکل، پروتکل استاندارد ایمن سازی ایمیل ها است.

4. امنیت Login : استفاده از کارت های هوشمند یا Smart Card ها ، Certificate ها در اینجا هم به کمک می آیند.

5. امنیت وب سایت: با استفاده از IIS 7.0 در ویندوز سرور 2008 به راحتی می توانید تراکنش های بین وب سرور و کلاینت ها را ایمن تر کنید.

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

7. امنیت شبکه های بی سیم: با استفاده از ویندوز سرور 2008 و ویندوز ویستا یا سون، می توانید مطمئن باشید که تمام ارتباطات در بین وسیله های مورد اعتماد است.

8. با استفاده از ویندوز سرور 2008 و Active Directory Rights Managment Services می توانید از اطلاعات در برابر کنجکاوی ها محافظت کنید.

 

ضمن آنکه مد نظر داشته باشید صادر کردن یک Certificate برای تمام کارمندان شرکت (کاربران شبکه) می تواند هویت آن ها را در هر تراکنشی تصدیق کند. با استفاده از AD CS یک (PKI (Public Key Infrastracure به صورت سلسه مراتبی در تمام شبکه ایجاد می شود که AD CS از اجزا و رول های مختلفی تشکیل شده که با تعدادی از آنها آشنا می شویم.

 

1. Certificate Authorities :

سرور هایی هستند که برای صدور و مدیریت مجوز ها به کار می روند. به اختصار آن ها را CAs می خوانیم. به علت ساختار سلسه مراتبی PKI، سرویس AD CS می تواند هم Root و هم Child ها را پشتیبانی کند. سرور CA که در  Root قرار دارد را Root CA می گوییم و معمولا Root CA مجوز هایی را CAs زیردست می دهند تا آن ها مجوز های لازم را برای کاربران صادر کنند. همانطور که می دانید هر Certificate دارای مدت زمانی برای خود است و بعد از آن منقضی می شود. زمانی که مجوز های Subordinate CA ها یا CA های زیردست، منقضی می شود آنها باید از Root CA دوباره درخواست تجدید مجوز را کنند. این دلیل آن است که Root CA در بازه های زمانی مشخصی در شبکه حاضر می شود و مجوز ها را تمدید یا مجوز های جدیدی صادر می کند. برای افزایش امنیت Root CA حتی به صورت فیزیکی Root CA را از شبکه خارج می کنند. در این خصوص در ادامه بیشتر بحث می شود. البته معمولا مدت زمان اعتباز مجوز یک Subordinate بیشتر از زمانی است که به کاربران، کامپیوتر ها و سرویس های دیگر مجوز می دهد.

 

2.CA Web Enrollment :

با استفاده از Web Entrollment کاربران برای درخواست یک Certificate و دریافت لیست مجوز های باطل شده  از طریق یک Web Browser به CA وصل می شوند. Certificate Revocation List یا به اختصار CRL لیستی از مجوز هایی است که توسط سازمان باطل شده است. به طور خاص این لیست فقط شامل شماره سریال مجوزها است. بر اساس RFC 3280 دو وضعیت مختلف برای Revocation وجود دارد که عبارت است از:

 

الف: Revoked : یک مجوز به صورت غیر قابل برگشت،باطل شده است. به عنوان مثال متوجه می شوید که CA یک مجوز به طور نا صحیح صادر کرده یا یک Private Key به سرقت رفته. در این حالت عمل باطل شدن مجوز غیرقابل لغو شدن است.

 

ب: Hold : یک مجوز به صورت قابل برگشت لغو می شود. برای مواردی کاربرد دارد که هنوز تصمیم قطعی گرفته نشده. به عنوان مثال تعلیق یک کاربر.

 

بر اساس RFC 5280 (صفحه 69) ده دلیل Revoke کردن یک مجوز به این شرح است:

 

CRLReason ::= ENUMERATED {
        unspecified             (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
             -- value 7 is not used
        removeFromCRL           (8),
        privilegeWithdrawn      (9),
        aACompromise           (10) }

 

CRL در بازه های زمانی مشخصی منتشر می شود و همچنین می تواند پس از آنکه یک مجوز باطل شد به صورت فوری منتشر شود. برای جلوگیری از حملات Denial Of Service و Spoofing معمولا CRL ها دارای یک امضای دیجیتال هستند تا مشخص شود حتما از CA مربوطه صادر شده اند. در این خصوص درآینده توضحات دقیق تری ارائه می شود.

 

از ویندوز سرور 2000 این ویژگی موجود بوده است و برای درخواست صدور یا تمدید مجوز ها برای کاربران و کامپیوتر هایی که در AD DS نیستند یا مستقیما به شبکه ارتباط ندارند و کامپیوترهایی که سیستم عامل آن ها مایکروسافت ویندوز نیست طراحی شده است. بر خلاف AutoEnrollment و Certificate Request Wizard که در ادامه با آن ها آشنا می شویم، از طریق اینترنت نیز امکان دریافت مجوز وجود دارد. کنترل کننده قبلی Xenroll.dll در ویندوز ویستا و سرور 2008 با کنترل کننده ی جدیدی به نام CertEnroll.dll جایگزین شده است و با آنکه فرآیند درخواست و صدور مجوز تغییری نکرده، در زمانی که کامپیوتری که سیستم عامل آن ویستا یا سرور 2008 است از کامپیوتری که یک سیستم عامل قدیمی تر دارد درخواست مجوز کند، مشکل compatibility ایجاد می شود. البته برعکس این امر صحیح نیست، یعنی سیستم عامل های قدیمی تر می توانند از سیستم عامل جدید تر مجوز دریافت کنند.

 

3. Online Responder :

مشابه CRL، یک OR هم برای تصدیق یک مجور به کار می رود. با استفاده از پروتکل Online Certificat Status Protocol یا به اختصار OCSP (توضیح در RFC 2560) این سرویس کار می کند. با استفاده از یک OR دیگر نیازی نیست که یک لیست  کامل CRL برای کنترل مجوز ها وجود داشته باشد. OR درخواست های تصدیق مجوز ها را دریافت می کند و آن ها را بررسی می کند و پاسخ می دهد. استفاده از Online Responder ها سریع تر و کارآمد تر است. AD CS به عنوان یک سرویس جدید در ویندوز سرور 2008 شامل این سرویس است. یک OR، در جواب یک درخواست سه جواب “Revoked” یا “Good” یا “Unknown” را باز می گرداند. این جواب توسط امضای OR، امضا می شود. چنانچه در پردازش درخواست مشکلی به وجود آید، OR یک Error Code را باز می گرداند. ORها از لحاظ امنیتی بسیار بحث برانگیز هستند که در آینده بحث خواهد شد.

 

4. Network Device Enrollment Service :

تجهیزاتی که دارای سیستم عامل سطح پایین هستند همانند روتر ها و سوییچ ها، نیز می توانند از PKIs بهره ببرند. با استفاده از پروتکل Simple Certificate Enrollment Protocol یا به اختصار SCEP که توسط سیسکو سیستمز ایجاد شده است، NDES نیز می تواند از PKIs استفاده کند. البته بدیهی است که این تجهیزات قسمتی از AD DS نیستند اما با استفاده از NDES می توانند با انکه دارای اکانت AD DS نیستند در ساختار سلسله مراتبی PKIs به خوبی جای بگیرند. NDES پیاده سازی مایکروسافت از روی پروتکل SCEP است که با آنکه تجهیزاتی همانند روتر و سوییچ نمی توانند توسط AD DS شناسایی شوند، بتوانند از مجوزهای CA استفاده کنند. بیشترین کاربرد NDES برای سازمان هایی است که دارایPKIs هستند و می خواهند ارتباط خودشان را با استفاده از IPSec با تجهیزاتی از شبکه ایمن کنند. در ویندوز سرور 2003 پکیج به نام Microsoft SCEP به صورت پکیج اضافه شونده قابل دسترسی است. البته Microsoft SCEP در واقع پشتیبانی مایکروسافت از SCEP است و یک پروتکل مجزا نیست. در ویندوز سرور 2008، با نام NDES این پشتیبانی به عمل آمد.

 

Crytography Next Generation – CNG .5 :

CNG در ویندوز سرور 2008 یک ابزار برای انعطاف پذیر برای توسعه ی رمزنگاری است. با استفاده از CNG می توان یک الگوریتم رمزنگاری جدید ایجاد، آپدیت یا از یک الگوریتم custom استفاده کرد. با CNG می توان عملیات ابتدای رمزنگاری همانند Hashها، رمزنگاری و رمزگشایی را انجام داد، می توان کلید های جدیدی ساخت، آنها را نگه داری کرد و آن ها را بازیابی کرد. می توان از Provider های دیگر استفاده کرد. برای اطلاعات بیشتر به اینجا، TechNet مراجعه کنید.

 

6. Restricted Enrollment Agent و Enrollment Agent :

Ristricted Enrollment Agent ویژگی جدیدی است که در ویندوز سرور 2008 معرفی شد. Enrollment Agents افرادی هستند که در یک سازمان مورد اعتماد هستند و برای آن ها مجوزی به نام Enrollment Agent Certificate صادر می شود. این افراد می توانند از طرف کاربران دیگر برای مجوز های Smart Card درخواست کنند. این افراد معمولا عضو تیم امنیت فناوری اطلاعات سازمان یا پشتیبانی باید باشند. البته در برخی سازمان ها همانند بانک ها که شعب زیادی دارند افراد تیم امنیت IT یا Help Desk نمی توانند این کار را بر عهده گیرند بنابراین این وظیفه بر عهده یک فرد دیگر همانند مدیر شعبه گذاشته می شود. CA در ویندوز سرور 2008، می توان مشخص کرد که یک Agent بتواند فقط برای گروهی از کاربران درخواست کند. روش کار چنین است که باید چند Security Templates مختلف طراحی شود و برای هر Template تنها فرد مربوطه به عنوان Enrollment Agent انتخاب شود. توجه داشته باشید که هنوز امکان آنکه که بر اساس یک OU این امر صورت گیرد وجود ندارد. شاید در آینده شاهد این تغییر مهم باشیم. همچنین توجه داشته باشید این ویژگی در Enterprise CA موجود است.

 

 

 

همانطور که گفته شد یک مجوز برای مدت مشخصی دارای اعتبار است، دلایل اصلی این امر عبارت است از:

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

2. time nesting : زمانی که CA Certificate باطل شود، تمام مجوز های صادر شده توسط آن نیز باطل می شود. CA Certificate خود زمان انقضا دارد و اگر منقضی شود، مجوز های صاده شده توسط آن CA هم باطل می شود مگر آنکه:

آ. قبلا باطل شده باشند.
ب. مجوز CA تمدید شود.

 

در پایان استاندارد هایی که در CA مایکروسافت استفاده شده به این شرح است:

RFC 2313 (PKCS #1). A method for encrypting data using Rivest-Shamir-Adleman (RSA) public key cryptography.

RFC 2527. A framework for creating certificate policies and certification practice statements for CAs and PKIs.

RFC 2528. Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Certificates.

RFC 2559. Addresses operational protocols that make it possible to retrieve data regarding X.509 certificates and CRLs from an LDAP directory.

RFC 2560. Guidelines for support of Online Certificate Status Protocol (OCSP).
Note

This requires the use of non-Microsoft OCSP software.

RFC 2585. Specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and CRLs from PKI repositories.

RFC 2587. Defines auxiliary object classes that need to be supported in an LDAP schema to support PKIX requirements.

RFC 2255. Guidelines for formatting LDAP URLs. Clarifies how LDAP URLs are resolved.

RFC 2797. Defines a certificate management protocol using Certificate Management Messages over CMS.

RFC 3280. Formatting of X.509 v3 certificates and X.509 v2 CRLs for use on the Internet.

 

 

این مطلب ادامه دارد

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

AD CS – قسمت سوم

CA های Stand-alone و Enterprise :

 

آ. Stand-alone CA : یک CA که لزوما به با AD DS یکپارچه نشده را می گویند. Stand-alone CA ها در معمولا روی یک Stand-alone Server نصب می شوند و  CA Client ها الزاما عضو دامین نیستند. صدور مجوز ها به صورت دستی باید تایید شوند. قالب امنیتی آن ها Standard Security Template است و غیر قابل تغییر است.  در ویرایش Standard ویندوز سرور هم در دسترس است.

 

ب. Enterprise CA : یک CA که با AD DS یکپارچه شده را می گویند. Enterprise CA ها روی Member-Server ها نصب می شوند و صدور مجوز ها از آنجا که CA با Active Directory Domain Service یکپارچه است، خودکار صورت می گیرد. قالب های امنیتی قابل ویرایش اند و بسیار پیشرفته تر از Stand-alone CA ها است. در ویرایش Standard ویندوز سرور در دسترس نیست و در ویرایش Enterprise یا Data Center موجود است.

ویژگی	Stand-alone	Enterprise
انتشار تنظیمات CA در اکتیودایرکتوری	اختیاری	اجباری
یکپارچه شدن اطلاعات CA در جنگل	اختیاری و دستی	اجباری و خودکار
انتشار CRL در اکتیودایرکتوری	اختیاری و دستی	اجباری و خودکار همچنین شامل Cross Certificate ها و Delta CRL می شود
Web Enrollment	پشتیبانی می شود	پشتیبانی می شود
درخواست مجوز از طریق HTTPS	پشتیبانی می شود	پشتیبانی می شود
متد درخواست مجوز	درخواست و انتظار تا تایید دستی	خودکار یا درخواست و انتظار تا تایید دستی
متد تایید مجوز	دستی	دستی یا خودکار با استفاده از Authentication اکتیودایرکتوری
نوع سرور CA	Stand-alone یا Member Server یا Server (دامین کنترلر)	DC یا Member Server فقط
نسخ سیستم عامل ویندوز سرور	Standard، Enterprise ، Data Center	Enterprise ، Data Center

 

همان طور مشاهده می کنید، تفاوت های این دو نوع سرور بسیار است و تصمیم گیری صحیح در طراحی بسیار اهمیت دارد. معمولا Enterprise در شبکه های داخلی که تعداد کاربران آن ها بسیار زیاد است استفاده می شود و فرآیند صدور مجوز بسیار آسان تر می شود اما این به معنای برتری Enterprise بر Stand-Alone نیست چرا که در برخی سناریو ها شرایط حکم می کند از Stand-Alone استفاده شود. در مرحله طراحی CA اولین فاکتوری که باید در نظر گرفته شود این مورد است. البته گام هایی که پیش از این در طراحی برداشته اید همانند Volume و… در این مرحله در انتخاب گزینه مناسب نقش کلیدی دارند. همچنین ممکن است در سناریو هایی به ترکیبی از این انواع دست بزنیم.

 

 

سلسه مراتب CA :

در مرحله طراحی اولیه، فاکتور بعدی که باید در نظر گرفته شود، امنیت با استفاده از سلسله مراتب است. این امر بسیار اهمیت دارد و کلید حل شدن بسیاری از مشکلات آینده است. از آنجا که ساختار CA سلسله مراتبی است، هر خطری که برای ROOT پیش آید، خطر تمام CA های زیر دست و به عبارت بهتر خطر تمام مجوز ها است. یکی از کارهای متداول یک معماری چندین مرتبه ای است و پس از پیاده سازی، سرورهای پر اهمیت خاموش می شوند یا از شبکه خارج می شوند سپس در برنامه های زمان بندی شده نا منظم، سرور را روشن یا به شبکه متصل می کنند تا به وظایف مدیریتی بپردازد. در این معماری، هر یک یا چند مرتبه را یک لایه تصور می کنیم و سپس ابتدا تعداد لایه ها را مشخص و سپس تعداد مرتبه های موجود در هر لایه را معین می کنیم. وسعت جغرافیایی، روابط Trust بین CA ها ، استفاده از کارت های هوشمند (Smart cards)، شبکه های بیسیم، تراکنش با افرادی خارج از شبکه محلی، IPSec و SSTP مواردی هستند که در این مرحله باید معین شوند چرا که در طراحی سلسله مراتب CA بسیار تاثیرگذارند.

 

- استفاده از یک CA که آن را گاها Single Root CA می خوانند، درموارد اندکی کاربرد دارد. زمانی که یک Single Root CA قصد دارید در نظر بگیرید، مهم ترین مسئله آن است که آن است که احتمال به خطر افتادن CA کم باشد و چنانچه مشکلی به وجود آید تاثیر بسیار مهمی نداشته باشد. با توجه به این دو شرط، در سناریوهای اندکی کاربرد دارد.

- ساختار دو لایه ای.  در لایه یک، Root CA وجود دارد که پس از راه اندازی و اقدامات مدیریتی اولیه خارج می شود و در بازه های زمانی نا منظم جهت مدیریت روشن می شود یا به شبکه متصل می شود. در لایه دو، تعدادی CA دیگر به دادن مجوز ها می پردازد. در اکثر کمپانی ها از این مدل استفاده می شود، چرا که وسعت و امکانات موجود اجازه ی افزایش لایه ها را نمی دهد.

- ساختار سه لایه ای. در لایه یک، Root CA وجود دارد که پس از راه اندازی و اقدامات مدیریتی اولیه خارج می شود و در بازه های زمانی نا منظم جهت مدیریت روشن می شود یا به شبکه متصل می شود. در لایه دوم، تعدادی CA را شامل می شود که آن ها نیز مشابه لایه یک خارج می شوند و در لایه سوم CA هایی موجود اند که مجوز ها را می دهند. معمولا در سازمان هایی که وسعت جغرافیایی قابل توجهی دارند و هزینه های این ساختار قابل توجیه است به کار می رود.

- ساختار های بیش از سه لایه.  ساختار های بیش از سه لایه ساختار های پیچیده ای هستند که در سناریو های خاص که تعداد کاربران بسیار زیاد، و اهمیت امنیت CA ها بسیار زیاد است کاربرد دارد.

همانطور که توجه می کنید با افزایش هر لایه عملیات مدیریتی چندین برابر می شود و فشار قابل توجهی به تیم فناوری اطلاعات کمپانی یا سازمان وارد می کند بنابراین انتخاب صحیح یا ساختار می تواند هم هزینه های نگه داری و هم هزینه های پیاده سازی را کاهش دهد. ضمن آنکه در نظر نگرفتن لایه های کافی ریسک به خطر افتادن زیرساخت CA را به مقدار قابل توجهی افزایش می دهد. در تصویر زیر به نوع و وضعیت online یا offline بودن CA ها توجه کنید.

 

 

چند نکته :

- تا جایی که ممکن است از ساختار تک لایه ای پرهیز کنید.

- Root CA که در لایه اول جای می گیرد باید به سرعت خاموش شوند، یک راه مناسب برای کاهش هزینه های پیاده سازی استفاده از تکنولوژِی Hyper-v در ویندوز سرور 2008 است که پس از انجام عملیات مدیریتی می توان کامپیوتر مجازی را خاموش کرد. جهت مسائل امنیتی حتما فایل های VM مربوط به کامپیوتر مجازی را از کامپیوتر حقیقی پاک کنید و آن ها را در یک محل ایمن نگه داری کنید.

- امنیت فیزیکی برای تمام CA ها بسیار اهمیت دارد.

- توجه کنید که مدیران CA ها افراد قابل اطمینانی باشند.

- امکان تغییر نام سروری که روی آن AD CS نصب می شود وجود ندارد.

- هر چند امکان پذیر است اما توصیه می شود، AD CS را روی DC نصب نکنید.

- علاوه بر مسائل فوق، مواردی که باید در مرحله طراحی اولیه در نظر گرفته شوند، زمان اعتبار مجوزها، نحوه درخواست مجوز، وجود کارت های هوشمند و… دیگری است که در ادامه مورد بررسی قرار می دهیم.

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

AD CS – قسمت چهارم

 

علاوه بر موارد ذکر شده، موارد دیگری هم هستند که در طراحی AD CS باید در نظر گرفته شوند. اولین مورد قابل توجه نحوه درخواست و توزیع مجوز ها است. همانطور که گفته شد یک مجوز برای تعیین هویت یک کاربر، وسیله یا برنامه به کار می رود. بنابراین باید مکانیسمی برای دادن مجوز صحیح به آن شیئ داشته باشیم. CA ها (نه فقط CA مایکروسافت) از مکانیسم های متعددی برای بررسی پیش از صدور مجوز هستند. یکی از سخت گیرانه ترین روش های متداول آن است که یک فرد با ملاقات حضوری با متقاضی دریافت مجوز، برای او مجوز صادر کند. برای آنکه مجوز امنیت بیشتری داشته باشد می تواند مجوز را روی یک وسیله سخت افزاری ایمن همانند کارت هوشمند به او تحویل داد پس از این وظیفه نگه داری از مجوز بر عهده ی شخصی است که مجوز به او داده شده است. اگر از Automatic Enrollment (صدور مجوز به صورت خودکار) استفاده می شود باید افراد پیش از آنکه توانایی دسترسی به شبکه را داشته باشند، تعیین هویت شوند. این کار با اخذ مدارکی همچون کارت پرسنلی و… قابل انجام است. این فرایند باید توسط مدیر ارشد IT و مدیر منابع انسانی پیش بینی شود.

 

مسئله بعدی مدت زمان اعتبار یک مجوز است. همانطور که گفته شد، معمولا Certificate ها دارای یک جفت کلید هستند. با کم کردن زمان اعتبار، ریسک به سرقت رفتن کلید ها کاهش پیدا می کند و به عبارت دیگر مدت کوتاه تر اعتبار، سبب افزایش قابلیت اطمینان به زیرساخت امنیتی می شود. اما کوتاه تر شدن مدت اعتبار سبب افزایش شدید عملیات مدیریتی می شود. همچنین زمان مجوز های خود CA ها نیز دارای اهمیت است. معمولا ROOT CA ها دارای بیشترین زمان هستند. پس از آن ها intermediate CA ها هستند. Issuing CA که CA هایی هستند که مستقیما با کاربران در ارتباط اند دارای زمان کوتاه تری هستند. به عنوان مثال ممکن است از یک فاصله ی 5 ساله برای ساختار سه لایه ای استفاده کنید به این ترتیب که، مجوز های صادر شده توسط Issuing CA دارای یک سال اعتبار باشند. مجوز Issuing CA دارای 5 سال اعتبار، Intermediate CA ها 10 سال و ROOT CA دارای 15 سال اعتبار باشد. همانطور که گفته شد، چنانچه مجوز یک CA باطل شود، تمام مجوز های صادر شده توسط آن از جمله CA های زیردست نیز باطل می شود بنابراین بازه های زمانی باید با دقت انتخاب شوند. اعداد ذکر شده تنها مثال بودند و در آینده در خصوص نسبت مناسب و چگونگی طراحی این زمان بیشتر بحث خواهد شد. 

 

 

نصب AD CS :

سروری که روی آن قصد نصب AD CS را دارید باید حداقل ویژگی های زیر را داشته باشد:

1. چند پردازنده داشته باشد، چرا که توان پردازشی بالا می تواند فرآیند واگذاری را تسریع کند.

2. مقدار RAM قابل توجه نیست و حداقل میزان RAM کفایت می کند. VM ها می توانند فقط 512MB RAM داشته باشند.

3. داشتن حداقل دو Hard disk جدا برای جدا کردن محل ذخیره سازی Database و logها. همچنین استفاده از تکنولوژی RAID در حالاتی که توازنی بین Reliability و Performance ایجاد می کند اکیدا توصیه می شود.

4. طول کوتاه تر کلید، سبب بیشتر استفاده شدن از دیسک می شود. طول بلند تر کلید سبب بیشتر استفاده شدن از CPU می شود. بنابراین تعادلی از این دو با توجه به شرایط سرور دارای اهمیت است.

5. سیستم عامل ویندوز سرور 2008 نسخه Standard فقط از Stand-alone CA پشتیبانی می کند. در نسخ کامل تر( Enterprise و DataCenter ) تمام قابلیت ها پشتیبانی می شود.

 

همچنین موارد زیر را در نظر داشته باشید:

- یک جنگل AD DS که حداقل دارای دارای یک دامین باشد.

- با توجه به طراحی شبکه و طراحی Certificate Server ها، کامپیوتر هایی که قرار است CA شوند در Server Farm های مناسب قرار داشته باشند. با توجه به لایه های، Issuing CA می تواند NDES هم باشد. توجه داشته باشید که برای نصب AD CS باید IIS نصب شود. البته نیازی نیست که پیش از نصب AD CS اقدام به نصب IIS کنید چرا که به صورت خودکار IIS و اجزای مورد نیاز نصب می شود.

 

پیاده سازی یک سناریوی ساده با AD CS سلسله مراتبی:

این سناریو، یک سناریوی متداول است و هر چند در اینجا فقط به مباحث آموزشی توجه می کنیم. در سناریوی زیر از سه سرور مختلف با نام های Server01 ، Server02 و Server03 استفاده می کنیم. همچنین زیرساخت های ارتباطی از پیش پیکربندی شده اند و همچنین AD DS در حال اجرا است. برای افزودن این سرویس جدید، در مرحله طراحی شبکه زیرساخت های لازم در نظر گرفته شده و اکنون قصد داریم مرحله پیاده سازی این سرویس را آغاز کنیم.

 

 

1. Server03 عضو دامین است. در این سرور قصد داریم Root CA را راه اندازی کنیم. یک رول جدید را می خواهیم اضافه کنیم. برای این کار در Server Manager روی گره Roles کلیک راست کرده و Add Roles را می زنیم.

2. مطالب توضیح داده شده را دقت می خوانیم و next را می زنیم. سپس در مرحله Select Server Roles گزینه Active Directory Certificate Services را انتخاب می کنیم و next را می زنیم.

3. در مرحله بعد، مطالب توضیح داده شده و معرفی سرویس AD CS را با دقت می خوانیم و Next را می زنیم.

4. با توجه به آنکه در حال راه اندازی Root CA هستیم و به زودی از شبکه آن خارج خواهیم کرد یا آن را Shut Down می کنیم، هیچ رول دیگری روی ان نصب نمی کنیم. فقط Certificate Autority را انتخاب می کنیم و next را می زنیم. ضمنا توجه کنید که رول های Network Device Enrollment Service و Cetrificate Autority نمی توانند هم زمان روی یک سرور نصب شوند.

 

 

 

5. در مرحله انتخاب نوع سرور گزینه StandAlone را انتخاب می کنیم و next را می زنیم.در مرحله بعدی Root CA را انتخاب می کنیم.

6. در مرحله Private Key؛ یک کلید خصوص جدید می سازیم. با توجه به آنکه در حال نصب اولین بار Root CA هستیم، مجبور به انجام این کار هستیم. چنانچه به دلایلی همانند System failures در حال نصب مجدد سرویس هستیم می توانیم از کلید ها موجود استفاده کنیم، هرچند توصیه نمی کنم. همچنین اگر در حال راه اندازی CA هستید که در سلسله مراتب یک CA غیر مایکروسافتی قرار دارد باید گزینه Select an existing private key on this computer را انتخاب کنید. توجه کنید که باید پیش از نصب رول CA کلید خصوصی را روی سرور نصب کرده باشید.

 

7. در بخش تنظیمات رمزنگاری (Cryptograohy) ابتدا Provider رمزنگاری را معین می کنیم، سپس الگوریتم hash و طول کلید را مشخص کرده و در پایان گزینه Use strong private key protection را در دسترس داریم که می توان به این طریق امنیت محکم تری را برای Root CA و… ایجاد کرد. در این بخش گزینه های متعددی داریم که تنظیم صحیح آن ها بسیار اهمیت دارد. به اختصار به چند نکته پایه اشاره می شود:

- هرچه طول کلید طولانی تر باشد امنیت محکم تر می شود اما پردازش بیشتری به پردازنده(ها) وارد می شود و به عبارت دیگر زمان بیشتری صرف امضای اسناد می شود، زمان بیشتری صرف کد کردن و دی کد کردن می شود.

 

- Cryptographic Service Provider یا CSP متوری است که Cryptographic Application Programming Interface یا API برای تولید زوج کلید استفاده می شود. CSP می تواند نرم افزار یا سخت افزار باشد. به عنوان مثال RSA#Microsoft Software key Storage Provider یک Provider مبنی بر نرم افزار و RSA#Microsoft SmartCard Key Storage Provider یک provider مبنی بر سخت افزار است.

 

- الگوریتم Hash، برای تولید و منصوب کردن یک مقدار Hash به یک زوج کلید است. به سادگی می توان گفت انتخاب الگوریتم متفاوت سبب می شود تا روش متفاوتی برای تولید Hash Value ایجاد شود.

 

- با استفاده ازگزینه use strong private key protection features provided by the csp می توان از استفاده های غیر تایید شده به وسیله ورود کلمه عبور یک مدیر پیش از هر عمل مربوط به رمزنگاری جلوگیری کرد.

 

8. با زدن next به گام بعدی می رویم. در این مرحله نام و پسوند CA را می توان معین کرد، در صورت نیاز آن ها را تغییر دهید.

 

9. در مرحله بعدی مدت زمان اعتبار مجوز را مطابق آنچه گفته شد معین می کنیم. در اینجا 20 سال را برای RootCA انتخاب می کردیم.

 

10. در مرحله بعدی باید محل ذخیره سازی Database و log را معین کنیم. همانطور که در نصب اکتیودایرکتوری گفته شده همواه توصیه می شود این دو محل کاملا از لحاظ دیسک مجزا باشند و همچنین گزینه های backup و RAID مناسب درنظر گرفته شود. با این حال در RootCA از آنجا که اغلب offline می شود از حساسیت کمتری برخوردار است. در RootCA هایی که از کامپیوتر مجازی استفاده می شود لازم است از زمان بندی های دقیق تر Backup استفاده شود.

 

11. در این مرحله ممکن است نصب IIS نیز لازم باشد. از آنجا که در اینجا پیش نیاز ها را رعایت کرده بودیم و IIS را پیش تر نصب کرده بودیم، با این مرحله مواجه نشدیم.

 

12. در مرحله آخر، باید تنظیمات معین شده را با دقت خواند تا از هر اشتباهی جلوگیری شود. لازم به توجه است که نام و دامین پس از آنکه رول CA نصب می شود نمی تواند تغییر کند. در صورت صحت اطلاعات نمایش داده شده، Install را می زنیم.

 

 

اکنون RootCA آماده شده است و می توان Issuing Server های دیگری راه اندازی کرد. حال قصد داریم در Server04 یک Subordinate CA راه اندازی کنیم. مراحل مشابه آن است که قبل انجام دادیم.

 

1. در مرحله CA Type ، گزینه Subordinate CA را انتخاب می کنیم.

 

2. در مرحله Certificate Request به صورت زیر عمل می کنیم:

- اگر CA والد در حال حاضر آنلاین است، گزینه Send a Certificate Request to a parent CA را انتخاب می کنیم و سپس بر اساس Computer Name با CA name و انتخاب Parent CA یک درخواست ارسال می کنیم.

- اگر CA والد در حال حاضر آنلاین نیست، گزینه درخواست مجوز را در محلی مناسب ذخیره می کنیم و پس از آنکه مجوز توسط Parent CA تایید شد، CA جدید می تواند شروع به کار کند. برای این کار گزینه Save a Certificate request to file را انتخاب می کنیم.

 

در این بخش نحوه نصب سرویس پایان می پذیرد و در قسمت بعدی با مدیریت های ابتدایی آشنا خواهیم شد

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

AD CS – قسمت پنجم

 

پس از نصب سرویس Active Directory Certificate Services اولین اقدامات مدیریتی برای راه اندازی اولیه سرویس عبارتند از:

1. تنظیم Certificate revocation

2.تنظیم قالب مجوز ها با توجه به فاکتور های زیر:

الف. چنانچه با استفاده از EFS در ذخیره سازی اطلاعات استفاده می شود، باید تنظیمات مربوط به این مسئله در نظر گرفته شود که شامل Recovery Agent نیز می باشد. Recovery Agent فردی است که در صورتی که کلید کاربر از دست برود می تواند اطلاعات را بازیابی کند.

ب. چنانچه با استفاده از مجوز ها ارتباط بی سیم(wireless) محافظت می شود، باید تنظیمات مربوط به این مسئله در نظر گرفته شود که شامل Authentication و Encryption اجباری برای تمام ارتباطات Wireless نیز می باشد.

ج. چنانچه با استفاده از کارت های هوشمند (Smart Card) تشخیص هویت افراد دو عاملی می شود، باید تنظیمات مربوطه در نظر گرفته شود. منظور از دو عاملی استفاده همزمان از کلمه عبور (چه چیزی می دانید؟) و کارت هوشمند (چه چیزی به همراه دارید؟) است. توضیح اضافه آنکه فاکتور دیگری به نام چه ویژگی دارید وجود دارد که شامل تشخیص هویت با وسایل بیومتریک است.

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

ه. موارد بسیاری دیگر که در اینجا صرف نظر شده تا در بحث خودشان دقیق مورد بررسی قرار گیرند.

3. تکمیل تنظیمات نحوه ی درخواست و صدور مجوز

 

تنظیم Certification Revocation برای یک سرور:

Revocation تنها ابزاری است که برای ابطال یک مجوز پس از صدور موجود است. پیش از این به برخی دلایل ابطال مجوز اشاره شد. بنابراین باید پیش از صدور مجوز تنظیمات مربوطه را اعمال کرد. یکی از ویژگی های Active Directory Certificate Services ، به روز رسانی و انتشار خودکار CRL است. بازه های زمانی توسط مدیر CA معین می شود تا این عمل صورت گیرد. این بازه زمانی به نام Publish Period مشهور است. پس از راه اندازی اولیه CA، بازه زمانی انتشار یک هفته، به صورت پیش فرض در نظر گرفته می شود. این بازه زمانی از روی Local time کامپیوتر معین می شود و دقیقا یک هفته یکبار از اولین راه اندازی CRL منتشر می شود. این بازه زمانی قابل تغییر است که در ادامه به آن خواهیم پرداخت. مسئله مهم دیگر، بازه زمانی دیگری است به نام مدت اعتبار CRL یا The Validity Period of CRL مقوله ای کاملا متفاوت با Publish Period است. بازه زمانی اعتبار CRL مدت زمان اعتبار یک CRL است که این مدت زمان برای شخص بازبینی کننده مجوزها تعیین می شود. تا زمانی که یک نسخه دارای اعتبار از CRL روی Cache سیستم Local موجود باشد، سیستم برای دریافت یک CRL جدید تلاشی نخواهد کرد. بازه زمانی انتشار CRL توسط CA administrator معین می شود. اما مدت زمان اعتبار CRL توسط اکتیو دایرکتوری، با افزودن به بازه زمانی انتشار معین می شود. به صورت پیش فرض اکتیو دایرکتوری این کار را با افزودن 10% زمان به بازه زمانی انتشار انجام می دهد. به عبارت دیگر چنانچه Publish Period بیست و چهار ساعت در نظر گرفته شود، آنگاه The Validity Period of CRL به مدت 26.4 ساعت در نظر گرفته می شود. البته این اضافه شدن زمان دارای سقف 12 ساعت است و چنانچه 10% اضافه بیش از 12 ساعت باشد، تنها 12 ساعت اضافه خواهد شد. به اضافه آنکه 10 دقیقه برای عدم توازن ساعت در نظر گرفته می شود. برای تعیین این بازه زمانی باید سنجشی بر روی امنیت و عملکرد صورت گیرد.(Performance & Security) بدیهی است بازه های زمانی طولانی تر انتشار CRL سبب می شود تا اطلاعات کلاینت ها از مجوز های باطل شده نا صحیح باشد و امکان سوء استفاده های احتمالی افزوده می شود. از جهت دیگر دریافت CRL در بازه های زمانی کوتاه تر سبب می شود تا باری بر روی سرورها، کلاینت ها و شبکه اضافه شود. از این رو انتخاب بازه زمانی مناسب با توجه به حساسیت ها و تعداد کاربران بسیار در این مرحله دارای اهمیت است.

 

با گذشت زمان لیست مجوز های ابطال شده، CRL، بسیار طولانی خواهد شد. به عبارت دیگر حجم این لیست زیاد می شود و چنانچه دفعات انتشار زیاد باشد بار سنگینی ایجاد خواهد کرد. لازم است تا راهکاری برای این مسئله یافت شود. برای این مسئله لیست دیگری از CRL ها ایجاد می شود به نام Delta CRL. به این طریق، کلاینت لیستی از جدید ترین Delta CRL ها را با لیستی از جدیدترین CRL ها ترکیب می کند و لیستی کامل و تقریبا به روز از مجوز های باطل شده دارد. از آنجایی که به صورت پیش فرض کلاینت دارای یک Cache برای CRL است، استفاده از Delta CRL می تواند عملکرد را بهبود ببخشد. برای استفاده از Delta CRL کلاینت ها باید از وجود Delta CRL آگاه باشند تا آن را برای مجوز های باطل شده چک کنند. چنانچه کلاینت از Delta CRL استفاده نکند، در هر زمان که Cache تجدید (Refresh) می شود برای دریافت CRL مجددا اقدام خواهد کرد. چنانچه از Delta CRL توسط برنامه ای که از certification Autority استفاده پیشتیانی نمی شود توصیه می شود از تنظیم Delta CRL خودداری شود.

 

در میان رخ داد دو زمان انتشار CRL می توان CRL را منتشر کرد. کاربر رایج این مسئله زمانی است که یک مجوز داری اهمیت ابطال می شود احتمال سوء استفاده از آن وجود دارد. چنانچه به صورت دستی در میان بازه زمانی CRL منتشر شود، بازه زمانی restart می شود به عبارت دیگر، بازه زمانی از آن زمان در نظر گرفته خواهد شد. مثلا، اگر بازه زمانی انتشار 7 روز باشد و در روز پنجم یک انتشار دستی صورت گیرد، انتشار خودکار بعدی، 7 روز پس از روز انتشار دستی در نظر گرفته می شود. نحوه انتشار دستی در ادامه توضیح داده می شود.

 

هر مجوزی که توسط Microsoft certification Authority صادر شده باشد دارای یک قسمت به نام CRL Distribution Point است. CRL Distribution Piont معین کننده ی آدرسی در شبکه است که به آن طریق می توان اعتبار مجوز ها را آزمود. به عبارت ساده تر این آدرس، محلی است که CRL ها و یا Delta CRL ها در آن ها قرار گرفته اند و به منظور بررسی آنکه آیا مجوز ابطال شده است یا خیر مورد استفاده قرار می گیرد. در خصوص معین کردن Distribution Point در ادامه بحث می شود. به صورت پیش فرض CRL و Delta CRL ها در مسیر Systemroot\System32\Certsrv\Certenroll قرار می گیرند. پسوند این فایل ها crl است و نحوه نام گیری آن ها به شکل زیر است:

 

myca.crl	CA مجوز CA خود را هیچ گاه تجدید نکرده یا با همان کلید فقط یک بار تجدید کرده است.
myca+.crl	Delta CA برای CA یک بار با همان کلید تجدید شده است.
myca(X).crl	CA به تعداد X بار مجوز CA را تجدید کرده به طوری که X>=1 است.

* myca نام سرور CA است.

 

1. معین کردن distribution point برای CRL

برای شروع کنسول Certification Authority را باز می کنیم. مثلا از طریق Administrative Tools. روی نام CA کلیک راست کرده و به زبانه Extensions می رویم. در لیست Drop-Down List گزینه CRL Distribution Point را انتخاب می کنیم. با استفاده از دکمه های Add و Remove می توان یکی از محل هایی CRL در آن قرار می گیرد را اضافه یا حذف کرد. با انتخاب هر کدام از این محل های ذخیره سازی CRL می توان گزینه های موجود در پایین Dialog Box را ویرایش کرد. با توجه به نوع CA و محل ذخیره سازی گزینه های مختلفی در دسترس اند. URL های مربوطه می تواند ldap، http، fille یا ftp باشد. از متغیر های زیر برای تعیین مسیر این URL می توان استفاده کرد.

 

CAName	نام CA
CAObjectClass	کلاس معرف CA برای استفاده در زمانی که از LDAP برای انتشار استفاده می شود.
CATruncatedName	نام کوتاه شده به 32 کاراکتر CA با استفاده از hash در پایان
CDPObjectClass	کلاس معرف CRL Distribution Point برای LDAP
CertificateName	نام CA با یک پسوند دیگر. مشابه متغییر اول است
ConfigurationContainer	محل Configuration container  در اکتیو دایرکتوری
CRLNameSuffix	افزودن یک پسوند به پایان نام فایل، در زمان Publish کردن CRL به یک فایل یا URL
DeltaCRLAllowed	در زمانی که Delta CRL منشر می شود، پسوند دیگری به جای پسوند CRLNameSuffix قرار می گیرد تا فایل ها متمایز شوند.
ServerDNSName	نام DNS سرور CA
ServerShortName	نام NetBIOS سرور CA

توحه شود یادگیری این متغیر ها اولویت نیستند چرا که به صورت پیش فرض مسیر های مناسب ساخته می شوند و می توان آن ها را باز تنظیم کرد. پس از انتخاب محل ذخیره سازی، باید گزینه های مربوطه را تنظیم کنیم که به شکل زیر است:

 

Publish CRLs to this location	استفاده از Location برای CRL distribution Point
include in all CRLs. Specifies where to publish in Active Directory when publishing manually	انتشار این Location در تمام CRL ها جهت زمانی که publish به صورت دستی انجام شود.
include in CRLs. Clients use this to find Delta CRL location	انتشار این Location در تمام CRL ها جهت پوینت کردن کلاینت ها به Delta CRL
include in the CDP extension of issued certificates	انتشار این Location در CDPs تمام مجوزهای صادر شده توسط CA
publish Delta CRLs to this location	استفاده از Location برای Delta CRL distribution Point
include in the IDP extension of issued CRLs	انتشار این Location در تمام CRL های منتشر شده (در IDP extension)

*بسیاری از دانشجویان در درک عملکرد  این گزینه ها مشکل دارند، توجه ویژه به جدول بالا بسیار با اهمیت است.

 

 

2. تنظیم بازه انتشار:

 

همانطور که گفته شد، تنظیم بازه انتشار اهمیت خاصی دارد، برای این منظور کنسول Certification Autority را باز می کنیم. مثلا در Run وارد می کنیم certsrv.msc ، دقت شود که پسوند msc وارد شود. در ساختار درختی سمت چپ، روی Revoked Certificates کلیک راست (RIGHT CLICK) می کنیم و Properties را می زنیم. سپس می توانیم بازه زمانی انتشار CRL، انتشار با عدم انتشار  Delta CRL و بازه زمانی انتشار Delta CRL را معین کنیم.

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

آشنایی با Active Directory و سرویس های آن

 

Active Directory Domain Services و سرویس های مرتبط آن، پیش نیاز و شکل دهنده ی شبکه های Enterprise بر اساس Microsoft Windows است. AD DS و سرویس های مشابه اطلاعاتی در مورد کاربران، کامپیوتر ها و سرویس های شبکه را نگه داری می کنند. این سرویس ها مکانیسمی برای Authenticate (شناسایی/ تشخیص هویت شدن) موارد ذکر شده را جهت دسترسی به منابع شبکه فراهم می آورند. در این بخش با مفاهیم اولیه آشنا می شویم.

در مهندسی نرم افزار، Directory یک راه حل هدایت کردن نام به مقدار است. به عنوان یک مثال ساده، می توان یک یک دیکشنری را یک دایرکتوری در نظر گرفت که در آن معنای یک لغت (اسم) به معانی واژه (مقدار) مربوط شده است. در یک دفترچه تلفن، اسامی اشخاص (نام-گره) به شماره تلفن های آن ها (مقدار-اطلاعات) مرتبط می شود و در DNS، نام DNS به IP address ها مرتبط می شوند. به عبارت دیگر می توان گفت؛ یک سرویس دایرکتوری تقریبا مشابه یک دیتابیس است.

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


در اینجا Directory Services عاملی برای Identity and Access یا IDA را فراهم می آورد. راهکار های IDA، راهکارهایی هستند که به سازمان ها کمک می کنند تا کاربرانشان را مدیریت کنند و حقوق دسترسی آن ها به منابع را معین کنند. مایکروسافت مجموعه ای از راهکار های مختلف را جهت IDA ارائه می دهد که مشهورترین آن ها Active Directory Domain Services است. اکتیو دایرکتوری دامین سرویسز در 1999 دیده شد و برای اولین بار همراه با ویندوز 2000 ارائه شد. پیش تر مایکروسافت نام NTDS را برای این سرویس انتخاب کرده بود.
یک IDA باید بتواند:


1. ذخیره سازی اطلاعات کاربران، گروه ها، کامپیوتر ها، وسایل سخت افزاری تحت شبکه و سایر هویت های لازم: در مفهوم جامع، هویت به هر شیئ فیزیکی یا منطقی که در شبکه نقش ایفا کند گفته می شود. بنابراین یکی از اجزای IDA باید محلی برای ذخیره سازی اطلاعات باشد که به آن Identity Store گفته می شود. Identity Store در اینجا همان Directory است. این دایرکتوری روی سرور هایی در شبکه نگه داری می شود که آن ها وظیفه اجرای AD DS را بر عهد دارند. به این سرور ها، دامین کنترلر گفته می شود. در محیط اکتیودایرکتوری گاهی، به دامین کنترلر ها به اختصار “سرور” گفته شود و سایر رول های سروری به صورت کامل گفته شود همانند DNS سرور.
2. تشخیص هویت: سرور به کاربر یا هر هویت دیگری اجازه نمی دهد به منابع شبکه دسترسی پیدا کند مگر آنکه آن هویت تشخیص هویت شود. اطلاعاتی که توسط کاربر یا هر هویت دیگری به سرور داده می شود با دایرکتوری مقایسه می شود و در صورت داشتن مجوز جهت دسترسی به آن Resource (منابع – همانند فایل) هویت می تواند دسترسی پیدا کند.
3. کنترل دسترسی: پس از تشخیص هویت میزان دسترسی هویت باید باید معین گردد.
4. روش های بازبینی: سازمان باید بتواند تغییرات و فعالیت هایی که در استفاده از IDA صورت می گیرد را بازبینی و مانیتور کند، بنابراین IDA باید مکانیسمی برای Auditing (بازبینی) وقایع داشته باشد.




IDA و راهکارهای مایکروسافت:

همانطور که پیش تر اشاره شد، اکتیو دایرکتوری، تنها مولفه موجود در راهکار های IDA نیست. همچنین اکتیو دایرکتوری نیز شامل 5 تکنولوژی مختلف است که شاید تنها یک یا دو مورد از این تکنولوژی ها بسیار معروف شده باشند اما هر کدام عملکرد های متفاوتی دارند. این پنج تکنولوژی یک راهکاری جامع برای IDA را ارائه می دهند که عبارتند از:



1. Active Directory Domain Services : این سرویس که توضیحاتی در خصوص آن پیش تر ارائه شد، برای مرکزی کردن فرآیند تشخیص هویت در شبکه استفاده می شود. همچنین با استفاده از Group Policy در AD DS می توان روی اشیاء گوناگون مدیریت کرد. با استفاده از جستجوی دایرکتوری، کاربران می توانند هر جزئی در شبکه را پیدا کنند؛ همانند File Server یا Print Server. این سرویس، اولین سرویسی است که باید در هر شبکه ی بر پایه Windows Server 2008 پیاده شود. مطالب مربوط به AD DS در آینده به طور کامل تحت پوشش قرار می گیرد. این سرویس نقش Identity را در مدل IDA مایکروسافت بر عهده می گیرد.
2. Active Directory Lightweight Directory Services : این سرویس که به اختصار AD LDS گفته می شود یک نسخه Standalne (غیروابسته، بدون نیاز به کامپیوتر دیگر می تواند کار کند) از اکتیودایرکتوری است. پیش از این این رول با نام Active Directory Application Mode یا ADAM ارائه شده بود تا از نرم افزار های یکپارچه به اکتیودایرکتوری پشتیبانی شود. می توان گفت AD LDS واقعا یک تکه کوچک تر AD DS است چرا که هر دو روی یک اساس هستند. AD LDS تنها اطلاعات مربوط به نرم افزار را نگه داری می کند. معمولا از AD LDS زمانی استفاده می شود که نرم افزارهایی به سرویس دایرکتوری نیازمند هستند اما لازم نیست اطلاعات آن ها در دامین کنترلر های محیط (سازمان) قرار گیرد. استفاده از AD LDS برای نرم افزار های نیازمند به سرویس دایرکتوری بسیار زیاد است که در آینده بیشتر مورد بررسی قرار می گیرد.

3. Active Directory Certificate Services : سازمان ها با استفاده از AD CS می توانند از امضای دیجیتال و زیرساخت های کلیذ عمومی برای تشخیص هویت استفاده کنند. پشتیبانی تشخیص هویت کاربران با استفاه از Smart Card (کارت هوشمند) و پشتیبانی از نرم افزار ها همانند Encrypted File System یا EFS؛ Internet Protocol Security یا IPSec و… به عمل می آید. AD CS یک روش موثر و ایمن برای مدیریت مجوز (Certificate) ها ارائه می دهد. این سرویس در آینده مورد بررسی قرار خواهد گرفت.
4. Active Directory Rights Managment Services : این سرویس که به اختصار به آن AD RMS گفته می شود یک راهکار مناسب برای حفاظت از اطلاعات است. هرچند با استفاده از ACL روی اسناد سازمان (مجوزهای دسترسی به فایل ها و فلدر ها) می تواند به صورت محدودی سطوح دسترسی کاربران را معین کرد اما این سرویس توانایی های بیشتری دارد. به عنوان مثال می تواند وضعیت های دسترسی در زمان داخل و خارج firewall را معین کند.این سرویس در آینده مورد بررسی قرار خواهد گرفت.
5. Active Directory Federation Services : این سرویس که به اختصار به آن AD FS گفته می شود،سازمان ها را قادر می سازد تا IDA را در پلتفرم های گوناگون بهره ببرند. به عنوان مثال در هر دو محیط ویندوزی و غیر ویندوزی. به عنوان مثال با استفاده از AD FS دو سازمان می توانند مدیریت کاربران جداگانه خود را داشته باشند اما به طور ایمن کاربران سازمان دیگر را برای دسترسی به برخی اطلاعات بپذیرند.
همانطور که مشاهده شد؛ تمام این 5 تکنولوژی یک راهکار جامع برای IDA ارائه می دهند. هر کدام از این راهکار ها یک عملکرد معین و منحصر به فرد دارد و ممکن است به یکی از تکنولوژی های دیگر جهت عملکرد وابسته باشد. اساسی ترین جزء این راهکار IDA را می توان AD DS و AD LDS دانست که به صورت Standalone یا در Domain سرویس دایرکتوری را فراهم می آورند.

در فرا تر از IDA :


هرچند سرویس های Active Directory را به عنوان یک راهکار جامع IDA معرفی شد، با این وجود Active Directory ویژگی های متعددی دارد که فرای آنچه به عنوان IDA می دانیم است. یک سری قوانین معین کننده ی کلاس های اشیا و ویژگی (صفات) آن هاست که در دایرکتوری قرار می گیرد. در واقع یک کاربر در محیط اکتیو دایرکتوری یک شیئ است که شامل ویژگی هایی همچون نام و نام خانوادگی، نام کاربری، کلمه عبور و… است. (Schema منظور است-در ادامه توضیح داده می شود) یک کامپیوتر که آن را نیز همانند یک کاربر دارای یک “account” است دارای کلاس متفاوتی است و ویژگی های متفاوتی با کاربر در مورد آن در دایرکتوری نگه داری می شود.


به عنوان مثال دیگر؛ مدیریت بر اساس سیاست های گروهی (Group Policy) موردی دیگر در فراتر از IDA است. با استفاده از سیاست های گروهی، بار کاری مدیر شبکه کاهش می یابد. در آینده در خصوص سیاست های گروهی در این مجموعه بسیار بحث خواهد شد و کسب اطلاعات بیشتر، بسیار مورد نیاز یک مدیر شبکه توانا است. همچنین اجزای بسیار دیگری که در آینده با آن ها آشنا می شویم.

سرویس دایرکتوری و جایگاه آن در راهکار های IDA مایکروسافت:


همانطور که پیش تر گفته شد، 5 تکتولوژی دایرکتوری تنها اجزای راهکار IDA مایکروسافت نیست. سرویس دایرکتوری به عنوان هسته اصلی این مجموعه در محوریت قرار دارد. با این وجود 4 راهکار دیگر در این مدل نقش های مهمی ایفا می کنند. آنچه در اینجا بسیار اهمیت دارید، الزاما در این مدل یک راهکار مشخص شده به معنای یک محصول ارائه شده از سوی مایکروسافت نیست، بلکه می تواند روش هایی باشد که در محصولات دیگر پیاده سازی می شود.

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

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

 

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

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

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 را بزنید.

اتوماتیک کردن مدیریت و ساخت کاربران

ساخت User Accounts ها فرآیندی است که بار کاری مدیران شبکه را افزایش می دهد. با توجه به مطالبی که در بالا ذکر شد، می توان به راحتی تمام اعمال مدیریتی مربوطه را انجام داد اما آن روش، روش کارا و مناسبی برای مدیریت کاربران نیست. اغلب در بین کاربران یک دامین ویژگی های مشابهی وجود دارد همانند امکان logon کردن در ساعات مشخص شده. در زمان ساخت یک user جدید می توان به سادگی از گزینه کپی کردن کاربر به جای ساخت یک کاربر جدید استفاده کرد. از زمان Windows NT 4.0، مفاهیم User Templates در ویندوز پشتیبانی می شد. User Template یک کاربر ساخته شده و آماده شده است که برای ساخت کاربر جدید از آن استفاده می شود. برای آنکه با این کاربر logon صورت نگیرد معمولا آن را Disable می کنند. پس از انجام این کار، اطلاعاتی از روی کاربر قدیم (Template) به کاربر ساخته شده کپی می شود که در هر زبانه به این صورت است:

1. General : هیچ اطلاعاتی کپی نمی شود.
2. Address : کدپستی، شهر، کشور کپی می شود اما آدرس کپی نمی شود.
3. Account : ساعت های logon، کامپیوتر هایی که می تواند Logon کند، تاریخ انقضای اکانت و Account Options کپی می شوند.
4. Profile : قسمت های profile path، logon Script و Home Drive و Home Folder Path کپی می شوند.
5. Organization: قسمت های دپارتمان، کمپانی و مدیر کپی می شوند.
6. Member of : گروه ها کپی می شوند.

تذکر: علاوه به مواردی که به صورت عادی در کنسول Active Directory Users & Computers موجود است، گزینه ها و موارد پر کاربرد دیگری نیز در دسترس است که برای دسترسی به آن ها باید از منوی View گزینه Advanced Features را انتخاب کرد. در این صورت گزینه هایی همانند Assitant و یا Employee ID نیز در دسترس خواهند بود که برخی از آن ها نیز کپی می شوند.

مفاهیم مربوط به  DN, RDN , CN

DN دقیقا مشابه یک مسیر برای اشیاء اکتیو دایرکتوری است. همانطور که با استفاده از مسیر c:\text\a.txt می تواند به فایل متنی رسید، DN یک روش مناسب تر برای رسیدن به اشیاء است. هر چند DN بسیار متفاوت از آن مثال است. هر شیء دارای یک DN یکتا خود است.

یک DN با شئ شروع می شود و به top level domain name ختم می شود. همانطور که پیش تر اشاره شد CN یا common name معرف شیئ است. OU معرف organizational unit است و DC معرف Domain Component.

قسمتی از DN که پیش از اولین OU است RDN یا relative distinguished name گفته می شود. از آنجایی که DN باید یکتا باشد RDN باید در دربرگیرنده (container) خود یکتا باشد.

استفاده از ابزار های مدیریتی روی خط فرمان:

دستور	کاربرد
dsadd	افزودن یک شیئ به اکتیو دایرکتوری
dsget	نمایش ویژگی های یک شیئ
dsmod	تغییر دادن یک ویژگی معین یک شیئ معین
dsmove	جا به جا کردن یک شیئ به یک container دیگر مثلا یک OU دیگر
dsrm	حذف کردن یک شیئ، تمام زیر مجموعه های یک شیئ container یا هر دو
dsquery	جستجو در اکتیو دایرکتوری

 

جستجو روی خط فرمان

با استفاده از دستور dsquery می توانید به جستجو در اکتیو دایرکتوری بپردازید. مشابه سایر دستورات اکتیو دایرکتوری به صورت کامل مستند سازی شده و با استفاده از دستور ?/ dsquery می توانید اطلاعات کامل کسب کنید. به عنوان مثال برای جستجو یک کاربر از dsquery user استفاده می کنیم یا برای جستجو یک گروه از dsquery group و برای کامپیوتر از dsquery computer استفاده می کنیم. به عنوان مثال برای یافتن کاربر که نام او با erf شروع می شود دستور زیر را وارد می کنیم:

c:\> dsquery user -name erf*

نتیجه جستجو چیزی مشابه زیر خواهد بود:

" CN=Erfan CN=Users,DC=contoso,dc=com"

چنانچه شیوه ی DN شیوه مطلوب شما برای مشاهده ی نتایج نیست می توانید از سوییچ o استفاده کنید. مثلا برای مشاهده logon name می توانید سوییچ o upn- را به دستور اضافه کنید. یا برای مشاهده نام کاربری مربوط به ویندوز قبل از 2000 سوییچ o samid- را اضافه کنید.

افزودن یک کاربر روی خط فرمان

الگوی زیر را برای وارد کردن دستور افزودن یک نام کاربری در نظر بگیرید:

dsadd user  [-samid ] [-upn ]
    [-fn ] [-mi ] [-ln ] [-display ] 
    [-pwd { | *}] [-desc ]  [-mustchpwd {yes | no}] 
    [-canchpwd {yes | no}] [-reversiblepwd {yes | no}] [-pwdneverexpires {yes | no}] 
    [-acctexpires ] [-disabled {yes | no}] 
   

توضیح آنکه هر سوییچ مربوط به کدام فیلد است در <> رو به روی هر سوییچ اضافه شده است. توجه فرمایید چنانچه از * در سوییچ pwd استفاده کنید، dsadd از شما برای کلمه عبور سوال خواهد کرد و روی صفحه نمایش داده نخواهد شد. همچنین توجه داشته باشید که را به صورت کامل و صحیح وارد کنید. به مثال زیر توجه فرمایید.

dsadd user cn=erfan,cn=users,dc=contoso,dc=com
  -fn erfan -ln taheri
  -pwd p@ssword!
 -disabled no

از طریق دستور DSadd می توانید تمام مشخصه ها را تنظیم کنید. برای کسب اطلاعات بیشتر به اینجا مراجعه کنید.

استفاده از CSVDE و LDIFDE

CSVDE یک ابزار خط فرمان است که با استفاده از آن می توان اطلاعات را از اکتیو دایرکتوری خارج یا به اکتیو دارکتوری وارد کرد. نوع فایل این ابزار می تواند به سادگی یک فایل متنی با شیوه نگارش صحیح باشد یا یک فایل CSV. می توان با استفاده از notepad یا Microsoft Office Excel نصب به ساخت این نوع فایل ها پرداخت. این دستور در اتوماتیک کردن فرآیند ساخت کاربران بسیار مهم و ساده است. الگوی کلی دستور به صورت زیر است:

csvde [-i] [-f filename] [-k]

پارامتر i معین کننده عمل import یا درون ریزی است و پارامتر f مشخص کننده نام و آدرس فایل ورودی یا خروجی است. سوییچ k برای در نظر نگرفتن خطای ناشی از وجود نظیر است. در اینجا منظور از وجود نظیر، وجود یک ویژگی نظیر یا یا شیئ نظیر با همان DN است. در این شیوه دیتا با استفاده از ویرگول به جای tab جدا می شود و به نحوی جدا می شود که هر قسمت مربوط به یک ستون از دایرکتوری است.

استفاده از CSVDE ها ضمن سادگی دارای معایبی نیز می باشد به همین جهت استفاده از LDIFDE توصیه می شود. در آینده در خصوص نحوه ساخت فایل CSV بیشتر بحث خواهد شد.

LDIFDE نیز برای درون ریزی یا برون ریزی اطلاعات از Active Directory استفاده می شود. Lightweight Directory Access Protocol Data Interchange Format یا به اختصار LDIF یک استاندارد Draft برای نوعی فایل است که برای انجام عملیات روی دایرکتوری هایی که از استاندارد های LDAP پشتیبانی می کند کاربرد دارد. در خصوص LDIFDE و نحوه استفاده از آن در آینده بحث می شود

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

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

جمعه ۱۳ نوامبر ۲۰۰۹

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

در گذشته توصیه می شد یک Domain Forest Root انحصاری در طراحی در نظر گرفته شود. Domain Forest Root به اولین دامین در جنگل (Forest) گفته می شود و Domain Forest Root انحصاری دامینی است که انحصارا جهت مدیریت زیرساخت های جنگل به کار می رود. این دامین شامل گروه های حساس کاربری همچون Enterprise Admins و Schema Admins را دارا می باشد و Operation Master های Forest-Wide در همین دامین پیش بینی شده اند. در تئوری پیش بینی شده بود که استفاده از Dedicated Domain Forest Root می تواند امنیت را بهبود ببخشد. در زیر Domain Forest Root انحصاری، بر اساس توصیه های اخیر یک دامین فرزند به صورت Global قرار می گیر و سایر اشیاء درون آن جای می گیرند. اکنون دیگر استفاده از Domain Forest Root انحصاری در تمام شبکه های Enterprise توصیه نمی شود و استفاده از یک دامین تکی در جنگل متداول ترین نحوه طراحی توصیه شده است. البته لازم به ذکر است هیچ متد طراحی واحدی وجود ندارد که برای هر سازمانی مناسب باشد پس لازم است تا با در نظر گرفتن شرایط طراحی مناسب به دست آید. طراحی مناسب امروز در بسیاری از سازمان ها مطابق تصویر فوق است.

با گذشت زمان، اکتیو دایرکتوری کامل تر شده و بهبود پیدا کرد است. توصیه های گذشته در امروز دیگر کاربردی ندارند. امروزه اکیدا توصیه می شود که از یک Single Domain در طراحی استفاده شود و افزودن دامین های دیگر آخرین گزینه انتخابی در طراحی ها قرار گیرد. نکات زیر می تواند در درک دلایل این تغییر کافی به نظر برسد.

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

2. هنوز هیچ ابزار مناسبی برای هرس کردن و قلمه زدن درخت ها وجود ندارد! به عبارت بهتر، نمی توان به طور قابل قبولی یک دامین را از یک درخت جدا و در یک درخت دیگر قرار داد. چنانچه این امر امکان پذیر بود، استفاده از Domain Forest Root انحصاری بیشتر می توانست مفید باشد.

3. در تنظیمات امنیتی می توان کمترین برتری ها را در نظر گرفت که اگر از ساختار Domain Forest Root انحصاری امن تر نباشد، ضعیف تر نیست.

بنابراین بهترین نحوه در زمان طراحی، ابتدا در نظر گرفتن یک Single Domain است که در صورت نیاز گسترش پیدا می کند. بزرگ ترین اشتباه در طراحی دامین های چندگانه اثر گرفتن از بخش ها و ساختار سازمان است. گاهی این اشتباه در طراحی ها بسیار به چشم می خورد که در ازای هر بخش از سازمان یک دامین فرزند طراحی شده است. طراحی ساختار درختی اکتیو دایرکتوری نباید الهام گرفته شده از بخش ها، دپارتمان ها و دفاتر یک سازمان باشد. ساختار چندتایی دامین ها باید به طور مستقیم از ویژگی های خود دامین ها مشتق شده باشد. با این حال، در برخی از سناریو ها استفاده از دامین های چندگانه الزام دارد.

1. یک Domain Partition که بین تمامی DC ها replicate می شود. اشیاء موجود در یک دامین  همانندUsers ، Groups ، Policies و Computers بین تمام دامین کنترلر ها در دامین Replicate می شود. اگر با توجه به توپولوژی شبکه لازم است تا اطلاعات مورد Replicate تقسیم شوند، باید از دامین های چندتایی استفاده شود. البته فراموش نشود که فرآیند Replication در AC DS بسیار اثر بخش است و می تواند اطلاعات دامین های بسیار بزرگ را با استفاده از پهنای باند پایین Replicate کند. در شرایطی که از لحاظ قانونی یا از نظر مشتری لازم است تا اطلاعات معینی برخی محل های نگه داری DC وجود نداشته یک روش موثر استفاده از دامین های چندتایی است. همچنین می توان با جلوگیری از ذخیره سازی آن اطلاعات مشخص در Domain Partition راه حلی ارائه داد. در هر صورت در این شرایط لازم است تا اطمینان حاصل شود که Global Catalog اطلاعات را Replicate نمی کند.

2. یک سیاست Kerberos. سیاست پیش فرض Kerberos برای اکثر شبکه ها کافی و موثر است اما برای داشتن یک سیاست متمایز لازم است از چند دامین در ساختار اکتیو دایرکتوری استفاده شود.

3. یک فضای نامی DNS. هر دامین تنها دارای یک نام DNS منحصر به فرد است. اگر چند فضای نامی متفاوت لازم است باید از چند دامین استفاده شود. با این وجود توجه به افزایش هزینه ها و ریسک ها پیش از انجام این عمل لازم است.

4. در دامین هایی با Functional Level پیش از Windows Server 2008 یک دامین تنها می تواند یک Password Policy و یک Account Lockout Policy منحصر به فرد داشته باشد. بنابراین در شرایط Functional Level گفته شده چنانچه سیاست مجزایی لازم است باید از چند دامین استفاده شود.

همانطور که گفته شد، استفاده از دامین های چندتایی هزینه های سخت افزاری، مدیریتی و نگه داری را به شدت افزایش می دهد. هر دامین به حداقل دو دامین کنترلر نیاز دارد که هر کدام از آن ها به امنیت فیزیکی، تهیه نسخ پشتیبان و… نیازمند است. حتی ممکن است با توجه به گستره جغرافیایی سازمان، به دامین کنترلر های بیشتری نیاز باشد. دامین های چندتایی فرآیند مدیریتی را نیز به طور چشمگیر افزایش می دهند. به عنوان مثال؛ انتقال یک شیئ بین دو دامین بسیار دشوار تر از بین دو OU است. غیر از هزینه ها، ریسک های امنیتی نیز بیشتر می شوند. یک تصور ناقص آن است که دامین یک مرز امنیتی است، در صورتی که یک Forest (جنگل) یک مرز امنیتی است. به عبارت دیگر در یک Forest، مدیران شبکه می توانند سبب زیان در تمام Forest شوند. در واقع خسارات بسیاری ممکن است از سوی یک اشتباه مدیریتی اتقاق افتد. ضمن آنکه یک مدیر بیشتر، به معنای افزایش خطای انسانی و افزایش امکان خیانت به اطلاعات شرکت توسط یک مدیر با هدف بد است. ساده ترین مسئله، می تواند سبب جلوگیری از سرویس دادن (Denial Of Service) شود و یا integrity تمام جنگل را زیر سوال ببرد.

به عنوان مثال مدیر شبکه در یکی از دامین ها یک گروه Universal می تواند بسازد که با GC همواره لازم است Replicate شود و با ساختن یک گروه و اضافه کردن اعضای بسیار زیادی در آن و ادامه این فرآیند می تواند سبب جلوگیری از سرویس دادن در شبکه شود. یا در یک مثال دیگر، هر مدیر شبکه در یکی از دامین ها می تواند یک نسخه پشیتیبان تاریخ گذشته مثلا مربوط به سال گذشته سازمان را Restore کند و تمام جنگل را دچار اختلال کند. در آینده در خصوص نحوه طراحی محیط اکتیو دایرکتوری بیشتر بحث می شود.

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

توجه داشته باشید که یک درخت یک فضای نامی پیوسته است. اگر به فضای نامی دیگری نیاز است باید درخت دیگری در جنگل در نظر گرفته شود. مطابق تصویر زیر:

جنگل های چند تایی

یک جنگل یک نمونه مستقل از محیط اکتیو دایرکتوری است. تمام دامین و دامین کنترلرها در یک جنگل Replicate های Schema و تنظیمات را دارا هستند و کاربرانی که در دامین ها هستند به نام Authenticated user شناسایی می شوند که هویت معینی در هر دامین دارند. مدیران مختلف شبکه هر یک وظایف معین و مناسبی برای خود دارند. چنانچه هر کدام از موارد فوق الزام آور نیست، توصیه می شود که از جنگل های چندگانه استفاده کنید. امروزه با استفاده از Active Directory Federation Services و Cross Forest Trust استفاده از شیوه جنگل های چند تایی در حال متداول شدن و بهترین راه کار است.

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

انتقال اشیاء بین دامین ها و جنگل ها – مباحث تئوری

 

در سناریو های چند دامینی عمل انتقال اشیاء بین دامین ها و جنگل ها بسیار صورت می گیرد. ممکن است حجم قابل توجهی از کاربران، گروه ها و کامپیوتر لازم باشد تا انتقال یابند. به دامینی که اشیاء از آن منتقل می شوند Source Domain و به دامین مقصد، Target Domain می گوییم. بر حسب وضعیت قرار گیری جنگل در عمل انتقال، انتقال به دو دسته تقسیم می شود:

1. Infra-Forest Migration : انتقال اکانت ها و بازسازی درون یک جنگل
2. Inter-Forest Migration : انتقال اکانت و بازسازی بین جنگل متمایز با جنگل Source Domain

در Inter-Forest Migration کپی از نسخه اکانت ها روی Target Domain ایجاد می شود و اکانت های روی Source Domain از بین نمی روند. این مکانیسم سبب می شود تا بتوان عمل انتقال را در چند فاز کاری مختلف انجام داد. پس از پایان عملیات انتقال و بازسازی ساختار Target Domain به سادگی می توان Source Domian را آفلاین کرد. در Infra-Forest Migration تنها با انتقال مستقیم از Source Domain به Target Domain انجام می شود و پس پایان عمل انتقال می توان ساختار را بازسازی کرد و OU  های جدید مورد نیاز را ایجاد کرد. سازمان ها که از ساختار دامین های چند تایی استفاده کرده اند از این روش برای انتقال به یک دامین جهت کاهش هزینه ها استفاده می کنند.

آشنایی با ابزار Active Directory Migration Tool

ابزار Active Directory Migratin Tools V3.1 می تواند اشیاء را میان Source Domain به Target Domain  منتقل کند. ADMT یک ویزارد برای انتقال کاربران، گروه ها، کامپیوتر ها، Trust ها و اکانت های سرویس را در اختیار شما قرار می دهد. همچنین می توان با استفاده از کنسول ADMT یا خط فرمان این کار را انجام داد. ADMT بسیار قدرتمند است و راه های مختلقی برای اتوماتیک کردن فرآیند وجود دارد. AMDT همچنین می توان با استفاده از VBScript یک اسکریپت تهیه و عملیاتMigration را انجام داد. همچنین ADMT امکان شبیه سازی را فرآهم می آورد که به این طریق می توان احتمال بروز خطا ها را بدون هیچ تغییر ارزیابی کرد. همچنین ویزارد این امکان را می دهد که پس از ارزیابی، انتقال را به زمان دیگری موکول کنید و به رفع خطاهای ارزیابی شده بپردازید. اکیدا توصیه می شود پس از رفع خطاهای ارزیابی شده، مجدد عملیات انتقال را ارزیابی کنید. این ابزار قابل دریافت از وب سایت مایکروسافت است و ورژن 3.1 آن از ویندوز سرور 2008 پشتیبانی می کند.

Security Identifiers و انتقال

پیش از انجام عمل انتقال لازم است تا بر SIDs مسلط بود. همچنین لازم است با مفاهیم Token، Access Control List و SIDHistory آشنا بود.

SID معرف هایی برای اشیا در دامین هستند که در تمام دامین یکتا هستند. مثلا در زمان ساخت یک کاربر، یک SID به آن تعلق می گیرد و زمانی که کاربر Logon می کند یک Token جهت دسترسی برای او صادر می شود که شامل SID کاربر است. همچنین آن Token شامل SID های گروه هایی که کاربر عضو آن ها است.منابع با استفاده از SD یا Security Descrptor ایمن می شوند. SD می تواند مجوز ها، مالکیت و Auditing (بازبینی) را برای معین کند. در SD در واقع دو ACL وجود دارد. Discretionary ACL که در واقع سطوح دسترسی به منبع را معین می کند. به Discretionary ACL به اختصار DACL گفته می شود. معمولا بسیاری از منابع آموزشی به جای استفاده از واژه DACL به اختصار از ACL استفاده می کنند. ACL دیگری که در SD موجود است System ACL یا SACL است که معرف Auditing روی آن منبع است. در DACL لیستی از اشخاصی که دارای دسترسی به منبع هستند وجود دارد که به هر کدام از آن ها ACE گفته می شود. ACE می تواند Allow یا Deny باشد. از آنجا که DACL مستقیما به SID کاربر مربوط است سطوح دسترسی کاربر به هر منبع از طریق SID خود و SD منبع صورت می گیرد. زمانی که کاربر تلاش می کند به یک منبع دسترسی پیدا کند، LSASS یا Local Security Authority Subsystem ابتدا SID کاربر را که در Token او موجود است با SID های موجود در DACL مقایسه می کند و سپس در صورت مجوز Allow به او مجوز استفاده از منبع را می دهد.

زمانی که اکانت ها از یک دامین به دامین دیگر انتقال پیدا می کنند، SID های جدید در Target Domain برای آن ها در نظر گرفته می شود تا با SID های قبلی دامین تداخل نداشته باشد. با توجه به آنکه SID ها باید یکتا باشند انجام این امر حیاتی است. بنابراین SID های اکانت ها در Target Domain با SID ها در Source Domain یکسان نخواهد بود. در واقع به صورت تکنیکال بهتر است بگوییم اکانت ها کاملا جدید است و به هیچ منبعی دسترسی ندارند. برای حل این مشکل دو راهکار وجود دارد.

1. SIDHistory: معمولا مدیران شبکه دوست دارند از SIDHistory برای کارآمد کردن بازسازی ساختار اکتیو دایرکتوری استفاده کنند. در یک Attribute به نام SIDHistory می توان SID های اکانت را ذخیره کرد و LSASS مشابه یک SID عادی با آن برخورد می کند و همچنان SID اکانت در دامین یکتا است.

2. Security Translation: فرآیندی است که طی آن SD های منابع با SID های Source Domain مقایسه می شوند و با SID ی Target Domain جایگذاری می شوند. به فرآیند باز ارتباط دهی SID ها RE-ACLing نیز گفته می شود. بدیهی است که انجام این فرآیند به صورت دستی خسته کننده و یا اصلا غیر ممکن است. ADMT می تواند این کار را به صورت خودکار انجام دهد. ADMT می تواند در خصوص موارد زیر Security Translation را به خوبی انجام دهد:

آ. File & Folder Permissions
ب. Printer Permissions
ج. Share Permissions
د. Registry Permissions
ه. User Rights
و. Local Profile که شامل تغییر مجوز های دسترسی فایل ها و پوشه ها نیز می شود.
ز. Group Membership

نکته مهم: فرآیند انتقال معمولا مدتی طول می کشد. از این جهت توصیه می شود از SIDHistory در زمان فرآیند انتقال استفاده کنید و سپس از Security Translation در پایان فرآیند استفاده کنید.

عضویت در گروه ها

آخرین نگرانی بزرگ در عمل انتقال برای دسترسی به منابع تغییرات در عضویت ها هستند. گروه های Global تنها می توانند از همان دامین عضو داشته باشند. بنابراین اگر یک کاربر به Target Domain کپی شود دیگر نمی تواند عضو آن گروه باشد. در Inter-Forest Migration برای حل این مشکل لازم است ابتدا Global Group ها به Target Domain را انتقال دهید. این گروه ها با استفاده از SIDHistory می توانند SID خود را نگه دارند و سپس انتقال کاربران را آغاز کنید. ADMT می تواند کاربر را در Target Domain دوباره عضو همان گروه کند. اگر گروه در Target Domain وجود نداشته باشد ADMT می تواند یک گروه جدید در Target Domain بسازد. در نهایت؛ کاربر در Target Domain به عضویت آن گروه در خواهد آمد و کاربر و گروه در SIDHistory خود دارای SID پیشین خود در Source Domain هستند و تغییر در دسترسی آن ها صورت نمی گیرد.

در Ifra-Domain Migration فرآیند با آنچه برای Inter-Forest Migration گفته شد متفاوت است. ابتدا گروه Global در Target Domainبه عنوان گروه Universal ساخته می شود. بنابراین می تواند شامل کاربرانی از هر دو دامین Source و Target باشد. گروه Universal جدید SID جدید می گیرد اما در SIDHistory خود SID گروه Global روی Source Domain را نگه داری می کند. پس از آنکه عمل انتقال کامل شد، Group Scope از universal به global تغییر می کند.

سایر نگرانی ها و راهکار ها

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

1. انتقال کلمه های عبور: ADMT می تواند کلمه های عبور را بدون توجه به سیاست های Target Domain منتقل کند. به عنوان مثال یک کلمه عبور خالی منتقل می شود. کلمه عبور جدید فعال خواهد ماند تا در زمان Expire شدن کاربر مجبور باشد با شرایط دامین جدید کلمه عبور انتخاب کند.

2. اکانت های سرویس: سرویس های روی کامپیوترها ممکن است از اکانت های دامین استفاده کنند. از آنجا که SID های این اکانت ها تغییر می کند ADMT به صورت خودکار اطلاعات سرویس را به روز می کند.

3. اشیائی که نمی توانند منتقل شوند: با آنکه ADMT ابزار قدرتمندی است دارای محدودیت هایی نیز هست. به عنوان مثال ADMT نمی تواند گروه های پیش ساخته یا Built-in را منتقل کند.

بهترین شیوه انجام یک سناریو ی انتقال

1. تهیه نسخه پشتیان به صورت کامل از Source Domain و Target Domain. همچنین اگر کامپیوتر هایی وجود دارند که در انتقال وجود دارند و روی آن ها به اشتراک گذاری منابع صورت گرفته و از Security Translation استفاده می شود توصیه می شود از آن ها نیز Backup گرفته شود.

2. ساخت یک کاربر آزمایشی و عضویت آن در یک گروه مناسب و انجام عملیات انتقال به صورت آزمایشی و در نهایت چک کردن دسترسی ها.

3. آزمایش سناریوی انتقال در یک محیط آزمایشی پیش از انتقال در محیط عملیاتی

4. برنامه ریزی برای Recovery و کسب اطمینان از آنکه برنامه Recovery کارا و صحیح است.

5. رمزگشایی کردن (Decrypt) فایل های رمزنگاری شده (Encrypted) توسط EFS و کسب اطمینان جهت اطلاع کاربران از این امر.

6. کسب اطمینان از آنکه زمان کامپیوتر ها با هم Sync است. زیرا Kerberos در صورت اختلاف از تشخیص هویت باز می ماند.

7. انجام عملیات انتقال

 

* لازم است با روابط Trust پیش از عمل انتقال آشنا باشید

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

مدیریت های اولیه در 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

10 نکته درباره DomainTrust اکتیودایرکتوری

1 - تعیین Trust متناسب با نیاز
پیش از این‌که یک Domain Trust را اعمال کنید، باید از متناسب بودن نوع آن با وظایفی که قرار است برعهده داشته باشد، اطمینان حاصل کنید. هر Trust بايد خصوصيات زير را داشته باشد:

Type: مشخص‌کننده نوع دامین‌هایی که در ارتباط با trust هستند.
Transitivity: تعیین می‌کند که آیا یک Trust می‌تواند به یک دامین Trust دیگر از طریق دامین سوم دسترسی داشته باشد.
Direction: مشخص‌کننده مسیر دسترسی و Trust (اکانت‌ها و منابع Trust)

Direction	Transitivity	Type
2way	Transitive	Parent and Child
2way	Transitive	Tree-root
1way OR 2-way	Nontransitive	External
1way OR 2-way	Transitive or Nontransitive	Realm
1way OR 2-way	Transitive	Forest
1way OR 2-way	Transitive	Shortcut

2 - با کنسول Active Directory Domains AND Trusts Console آشنا شوید

روابط بين Trustها از طریق کنسول Active Directory Domains AND Trusts Console مدیریت می‌شود. این کنسول به‌شما اجازه خواهد داد تا اعمال اساسی زیر را انجام دهید:

- ارتقاي سطح عملیاتی دامین
- ارتقاي سطح عملیاتی Forest
- افزودن Suffixهای UPN
- مدیریت Domain Trust
- مدیریت Forest Trust

برای اطلاعات بیشتر درباره جزئیات این ابزار به آدرس زیر مراجعه کنید:

http://techrepublic.com.com/5100-6345_11-5160515.html

3 - آشنايی با ابزار
همانند دیگر اجزاي خانواده ویندوز سرور، ابزار خط فرمان می‌تواند برای انجام فرامین تکراری یا جهت اطمینان از سازگاری و هماهنگی در زمان ایجاد Trustها به‌کار آید. برخی از این ابزارها عبارتند از:

- NETDOM: برای برقرار کردن یا شکستن انواع Trustها استفاده مي‌شود.
- NETDIAG: خروجی این ابزار وضعیت پایه‌ای را در روابط بين Trustها به‌دست می‌دهد.
- NLTEST: برای آزمایش ارتباطات Trust مي‌توان از آن استفاده کرد.

شما همچنین می‌توانید از ويندوز اکسپلورر برای مشاهده عضویت‌ها در منابع مشترک آن‌گونه که در دامین‌های Trust و/ يا Forest تعریف شده، استفاده کنيد. کاربران AD همچنین می‌توانند جزئیات عضویت آبجکت‌هاي اکتيو دايرکتوري‌اي که اعضايی از دامین‌های Trust و/ يا Forest دارند، مشاهده کنند.

4 - ایجاد یک محیط آزمایشی
بسته به محیط و نیازمندی‌های شما، یک اشتباه ساده در ایجاد Trust دامین‌ها می‌تواند به بازتاب‌هایی در سطح کل سازمان منجر شود. با وجود اين، فراهم ساختن یک محیط آزمايش مشابه براي Replicate کردن موارد مربوط به چندین دامین و فارست کار دشواری خواهد بود. ایجاد دامین‌هایی برای سناریوهای مشابه کار آسان‌تری بوده که برای استحکام زیرساخت‌ها و آزمایش کارکردهای اساسی می‌توان از آنان استفاده کرد.
 
علاوه بر اين، قبل از استفاده از گروه‌هاي زنده، اکانت‌ها و آبجکت‌هاي ديگر، به آزمايش الگوي آبجکت‌ها دايرکتوري روي روابط دامين زنده توجه کنيد تا مطمئن شويد که ميزان دلخواه عامليت به‌دست آمده، نه بيشتر.

5 - مجوزها را بازبینی کنيد

وقتی Trustها ایجاد شدند باید از عملکرد دلخواه آنان اطمینان حاصل شود. اما مطمئن شوید که برای بررسی صحت جهت دسترسی، Trust پیکربندی‌شده دوباره بازبینی شود. به‌عنوان مثال، چنان‌چه دامین A بايد فقط به منابع معدودی روی دامین B دسترسی داشته باشد، یک Trust دو طرفه کفایت خواهد کرد.

هرچند ممکن است لازم باشد یکی از مدیران دامین B بتواند به تمام منابع دامین A دسترسی داشته باشد. از صحت جهت و سمت، نوع و Transitivity همه Trustها اطمینان حاصل کنید.

6 – طرح Trustها را تهيه كنيد
نقشه‌اي ساده با استفاده از پيكان‌ها و جعبه‌هايي كه نمايان‌گر دامين‌هاي داراي Trust، ارتباط آنان با يكديگر و اين‌كه اين Trustها يك‌طرفه هستند يا دو طرفه تهيه کنيد. با استفاده از تصوير‌(هاي) ساده مشخص كنيد، كدام دامين به كدام دامين ديگر Trust دارد و Transitivity آن‌ها را نمايش دهيد.

اين جدول ساده موجب درك بهتر وظايف محوله شده و به شما اجازه خواهد داد تا دامين‌هاي نيازمند به جهت دسترسي (Access Direction) و همچنين جهت صحيح را مشخص ساخته و نمايش دهيد. برخي از دامين‌ها فقط نقش يك دروازه ساده را براي دسترسي به ديگر دامين‌ها ايفا مي‌کنند.

7 – ارتباطات بين Trustها را مستند كنيد

امروزه، سازمان‌ها دائم در حال پيوستن و جدا شدن از يكديگر هستند. به‌همين دليل، اين نكته اهميت دارد  كه نقشه واضحي از ارتباط بين دامين‌ها و Trustهاي بينابين تهيه شده تا همواره از وجود اطلاعات لازم بدون نياز به مراجعه به كدهاي مربوطه اطمينان حاصل شود.

به‌عنوان مثال، اگر شما روي دامين B قرار داشته باشيد و دفتر مركزي شما روي دامين A نمايندگي شما را ابطال و Trust را قطع كند، يك سند كوچك و مختصر كه قبلاً روي دامين A ذخيره شده كمك بسيار بزرگي براي شما خواهد بود.

نوع Trust، جهت، ملزومات تجاري مورد نياز براي آن Trust، مدت اعتبار پيش‌بيني شده براي Trust، مجوز، اطلاعات پايه‌اي دامين و فارست (شامل نام، DNS، آدرس IP، مكان فيزيكي، نام كامپيوترها و...) و اطلاعات تماس فرد يا افراد مسئول دامين‌ها از اطلاعاتي هستند كه ذخيره‌سازي آنان در يك محل مطمئن بسياري از كارها را آسان‌تر خواهد کرد.

8 – از پيچيده کردن ارتباط Trustها پرهيز کنيد

براي صرفه‌جويي در وقت و زمان، از جلو بردن عضويت‌ها در بيش از يك لايه هنگام كار و استفاده از Trust در دامين‌ها و فارست‌هاي چندگانه پرهيز كنيد. با اين‌كه تودر تو کردن عضويت‌ها مي‌تواند به يكپارچگي و كاهش آبجکت‌هاي قابل مديريت در AD كمك کند، اما اين‌کار موجب افزايش ميزان تصميم‌گيري در مديريت اعضا خواهد شد.

9 – چگونگي مديريت نسخه‌هاي مختلف ويندوز
وقتي AD را روي ويندوز 2000 و ويندوز سرور 2003 اجرا مي‌كنيد، امكانات كامل براي دامين‌ها و فارست‌هاي عضو فراهم خواهد بود. چنان‌چه هرگونه سيستم عضو يا دامين NT در سازمان حضور داشته باشند، امكانات ورودي Trust آن‌ها به‌دليل ناتواني در شناسايي آبجكت‌هاي AD محدود خواهد شد. راه‌حل عمومي اين سناريو ايجاد «دامين‌هاي جزيره‌اي» براي آن دسته از افرادي است كه معمولاً به ساختارهاي عمومي سازمان متصل نمي‌شوند.

10 – Trustهاي منقضي و Overlap شده را پاك كنيد

تغييرات ايجاد شده در روابط مابين سازمان‌هاي تجاري ممكن است موجب برجاي گذاشتن تعدادي از Trustهاي بدون استفاده در دامين شما شود. هرگونه تراستي را كه به‌عنوان فعال مورد استفاده قرار نمي‌گيرد، از روي دامين برداريد. همچنين از تنظيم صحيح تراست موجود و مطابقت آن‌ها با دسترسي مورد نياز و الگوي استفاده اطمينان حاصل كنيد. بازرسي و رسيدگي به جدول تراست مي‌تواند مكمل خوبي براي سياست‌هاي استحكام يافته امنيتي شما به‌حساب آيد.
منبع:www.shabakeh-mag.com

primary کردن یک secondry additional server

 

دراین سناریو ما فرض میکنیم که یک primary server  با نام server1 و یک additional server با نام server 2 داریم.وظیفه server2 در مدار قرار کرفتن به عنوان dc در مواقع خرابی server1  میباشد.

حال فرض کنیم به علت خرابی یا .... هر علت دیگر مایل میباشیم server1  را حذف کرده و server2 را تبدیل به primary server کنیم.

(این مسئله برای من بدینگونه اتفاق افتاد که سرور 1 را چون سرور قوی بود و در ضمن از همه توانائی آن استفاده نمیشد قرار بود آزاد کرده و در جای دیگری استفاده نمایم)

ابتدا از raise بودن هر دو active directory  مطمئن شوید.

1)سپس active directory site and service را گشوده و operating master  را برای هر 3 مورد PDC,RID,infrastructure  روی سرور 2 تنظیم نمایید.

2)global catalog را از همین بخش به سرور جدید تغییر دهید.

3)در active directory domain and trust گزینه operating master  را نیز به سرور2 تغییر دهید.

4)در سرور 2 از طریق کنسول mmc عمل فراخوانی schema manager را انجام دهید.اگر این گزینه جزء کنسول شما نبود از طریق اجرای دستور زیر در  run  آنرا نصب نمایید.

run:regsvr32 schmmgmt.dll 

5)در سرور 1 با دستور dcpromoعمل حذف active directory  را انجام دهید.

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