بهترین نرم افزارهای امنیتی رایگان 2017

چهارشنبه 28 تیر 1396 ساعت 16:34



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

 

 

بهترین نرم افزارهای امنیتی رایگان 2017

Unchecky
بد افزارها و Tool bar ناخواسته را قبل از نصب، شناسایی می کند
از این نرم افزار نمی‌توایند برای حذف نرم افزارهای مخرب استفاده کنید اما این نرم افزار به شما کمک می‌کند هنگام نصب نرم افزارها، تیک‌های اضافی را بردارید و اگر نرم افزاری، در حال نصب برنامه‌های اضافی روی سیستم شما باشد، به شما هشدار می‌دهد.

این نرم افزار به عنوان یک نرم افزار امنیتی، به هیچ وجه کامل نیست، نمی‌تواند همه‌ی نرم افزارهای ناخواسته را تشخیص دهد.

با استفاده از این نرم افزار همراه با رعایت توصیه‌های امنیتی (نرم افزارها را فقط از جاهایی که قابل اطمینان‌اند دانلود کنید، هنگام نصب از گزینه‌ی custom install استفاده کنید و در هر قدم از نصب نرم افزار همه‌ی گزینه‌ها را به دقت مطالعه کنید) می‌توانید از نرم افزارهای ناخواسته‌ای که ممکن است ایمنی شما را به خطر بیندازند دوری کنید.

 

 

 

 

360 security

نرم افزار 360 security بهترین و محبوب ترین برنامه ی امنیتی که به صورت رایگان برای سیستم عامل اندروید طراحی شده است.

امکانات امنیتی نرم افزار ۳۶۰Security : اسکن اپلیکیشن های نصب شده، حافظه RAM و اپلیکیشن های در حال نصب برای یافتن موارد مشکوک می باشد.

این نرم افزاز، سیستم ضد سرقت هم دارد که با آن می توانید تلفن همراه خود را از راه دور به طور کامل قفل کنید، Alarm آن را به صدا دربیاورید، اطلاعاتان را پاک کنید یا مکان جغرافیایی آن را از طریق gps پیدا کنید.
این نرم افزار هم رقیبای جدی ای مثل lookout ، CM Security و اپ های آنتی ویروس های مطرح دارد.

دانلود Kaspersky Antivirus Internet Security 2018

چهارشنبه 28 تیر 1396 ساعت 16:33


– محافظت در مقابل انواع ویروس ها، تروجان ها و کرم های اینترنتی

– محافظت در برابر انواع Spyware، Adware، Worms، Trojans، Virus و دیگر برنامه های مخرب

– محافظت در مقابل اسپم (نامه های ناخواسته)

– جلوگیری از ظاهر شدن پنجره های تبلیغاتی مزاحم (pop-up)

– برگرداندن تغییرات ایجاد شده توسط برنامه های مخرب

– قابلیت کنترل و عدم اجازه دسترسی دیگران کاربران به برخی از سایت های اینترنتی

– برگرداندن تغییرات ناحواسته به حالت قبلی

– دارا بودن ابزارهایی لازم برای نجات دادن هارد دیسک از بحران

– محافظت برنامه از خود در برابر متوقف یا از کار انداخته شدن!

– گرفتن جدیدترین اخبار از Kaspersky Lab به وسیله کامپوننت News Agent

– به روز رسانی اتوماتیک

دانلود Kaspersky Antivirus Internet Security 2018


قابلیت های نسخه جدید این نرم افزار ها:

– بهبود مقابله با حملات ناشناخته

– بهبود مقابله با حملات از طریق مسنجر هایی مانند یاهو و ام اس ان و ICQ

– بهبود فایروال شخصی سیستم

– برقراری امنیت کامل برای شبکه های VPN و بیسیم Wi-Fi

– اضافه شدن ابزار های کنترل هوشمند

– بهبود سیستم حفاظتی

– اسکن سیستم عامل به صورت اتوماتیک برای برنامه های نصب شده که به صورت مخفی خرابکاری می کنند

– اسکن اینترنت اکسپلورر و جلوگیری از حملات مخفی از طریق این مرورگر

– جلوگیری از ورود به سایت هایی که حاوی Maleware می باشند

– مانیتور کرد حملات دسته جمعی به سیستم

– برگشت تنظیمات صحیح سیستم بعد از پاک نمودن حملات خرابکارانه

– بهبود جلوگیری از حملات Phishing

– اضافه شدن یک کیبورد مجازی برای ورود رمز های عبور و جلوگیری از دزدیده شدن رمز های عبور توسط key logger ها

Best Practice های مایکروسافت درباره طراحی Site Topology

پنج‌شنبه 15 تیر 1396 ساعت 11:51
بعد از برسی مفاهیم و اصطلاحات replication همچنین نحوه عملکرد آن نوبت به نحوه طراحی این پروسه مهم می رسد.
بیشتر توپولوژی های شبکه بصورت

    Ring
    Hub and Spoke
    Complex


می باشد.Forest owner (مسئول کل ساختار AD Forest و مسئول طراحی Site topology) این دو نفر یا تیم طراحی قبل از طراحی و اجرای این پروسه باید اطلاعات زیر را بدست آورند:
یک نقشه که دارای اطلاعات زیر باشد:

    تعداد کاربران و کامپیوترها در هر یک از سایتها
    سرعت لینک ارتباطی سایتها به همدیگر
    IP Address های که به هر یک از سایتها اختصاص می یابد.

اطلاعات لازم برای هر سایت:

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

اطلاعات لازک برای Site linkها:

    هر سایت لینک چه سایتهای را به همدیگر وصل می کند.
    مقدار Cost که به Site link ها اختصاص می یابد.
    زمان بندی و تعداد دفعات Replication برای Site linkها
    محاسبه زمان تاخیر یا Latency بین سایتها.

خدا رو شکر تمام اصطلاحات بالا را در مقالات پیشین توضیح و آموزش دادم.
مسئول site topology باید فردی باشد که تمام اطلاعات لازم درباره نحوه عملکرد این پروسه را دارا باشد. چون تعقیراتی که این فرد انجام خواهد داد تاثیر مستقیمی بر روی نحوه Replication در کل فارست دارد. وظایفی که این فرد بر عهده دارد در جدول زیر مشخص است:

و اما توصیه های مایکروسافت درباره طراحی Site topology:
مدیر و مسئول این تنظیمات را باید مشخص کنید و مجوز این کار را برای او واگذار کنید. (درباره ساختارهای حرف می زنیم که حداقل 200 سایت دارد نه یک شعبه کوچک که همه کارها را یک نفر انجام دهد)

    در صورت امکان برای inter-site replication تنظیمات را بصورت پیش فرض رها کنید ( Connection object یا Bridgehead server را دستی ایجاد نکنید)
    KCC را غیرفعال نکنید.
    قابلیت Transitive یا Bridge را بر روی Site linkها غیرفعال نکنید.
    در صورت امکان زمان بندی را بصورت Full access تنظیم کنید.
    زمان تاخیر یا Latency بین سایتها را محاسبه کنید.
    Practice های مایکروسافت درباره طراحی Site linkها:
    سایت لینکها را به WAN linkها مپ کنید.
    یک سایت نباید بصورت مستقیم بیشتر از 20 سایت متصل باشد.

این کانکشن می تواند برای شبکه های بزرگ که از توپولوژی Hub and spoke استفاده می کنند رخ دهد. برای حل این مشکل می توانید سایت hub را به چند سایت تقسیم کنند و تعداد Bridgehead server ها را گسترش دهید تا بتوانند حجم اطلاعات Replication را هندل کنند.
طراحی Site topology طبق BP های مایکروسافت شامل مراحل زیر می باشد.

    ایجاد یک نقشه از مناطق (سایتها) فعالیت سازمان.
    قرار دادن DC در این مناطق.
    ایجاد شی Site برای هر یک از این مناطق.
    اتصال سایتها توسط Site link.
    ظرفیت و گنجایش DC ها.
    ایجاد یک نقشه از مناطق (سایتها) فعالیت سازمان

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

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

برای هر یک از این مناطق پارامترهای زیر را تعیین کنید.

    تعداد User ها
    تعداد کلاینتها
    Subnetهای مورد استفاده

برای هر یک از لینکهای ارتباطی این مناطق پارامترهای زیر را در نظر بگیرید:

    سرعت لینک ارتباطی
    مقدار استفاده شده از پهنای باند هر کدام از لینکها


قرار دادن Domain controller برای هر یک از این مناطق:
یکی از چیزهای مهمی که مایکروسافت در ابتدای این مرحله اشاره می کند این است که اگر به هر دلیلی لینک ارتباطی یکی از این مناطق fail شد کاربران آن منطقه باید بتوانند به دومین خود Logon کنند.
اولین جائی که باید ارزشیابی شود منطقه اصلی یا hub site می باشد. بعد از تعیین تعداد DCهای سایت اصلی باید اینکار را برای بقیه مناطق انجام دهیم. همچنین ممکن است برای مناطق خیلی کوچک که تعداد کلاینتها و کاربران کمتر از 10 یا 15 عدد باشد DC ی مشخص نشود. در شکل زیر سایتهای سازمان همراه با دومین های آن و تعداد DC های که برای هر Domain مشخص شده است را می بینید:

قانون اول: برای هر Hub site (به علت بزرگ بودن بعضی از ساختارها، سایت اصلی به چندین سایت تقسیم می شود) یک Additional DC از Forest root domain ایجاد کنید. بخاطر داشته باشید برای هر کاربری که می خواهد به منابع دیگر Domain ها دسترسی داشته باشد حتما باید با DC های Forest root domain ارتباط برقرار کند. بخاطر همین دلیل هر سایتی که زیر مجموعه ای از سایتهای دارد، قرار دادن یک Additional DC از Forest root domain الزامی باشد.
For each of your hub sites, place one domain controller from the forest root domain. For each satellite location, evaluate the need for a forest root domain controller. Keep in mind that for a client to access a resource in a domain other than its own, communication must occur with a forest root domain controller. For this reason, any location that has domain controllers from two or more regional domains should also have a forest root domain controller
قانون دوم: برای هر منطقه ای یا سایتی که تعداد کاربران آن زیاد باشد برای تسریع در پروسه Logon کاربران و صرفه جوئی در پهنای باند لینک ارتباطی آنها حتما در آن سایت از یک یا دو DC (حداقل) ایجاد شود.
قانون سوم: هر Domain دارای یک نقش PDC emulator می باشد. DCی که این نقش را نگهداری می کند باید:
بهترین اتصال با بقیه سایتها داشته باشد. (Domain directory partition یکسانی داشته باشند)
در سایتی نگهداری شود که بیشترین تعداد کاربران مربوط به آن Domain در آن فعالیت کنند.
قانون چهارم: حداقل برای هر سایت یک GC باید فعال باشد. BP مایکروسافت می گوید بهتر است نیمی از DCهای سایت GC باشند. اگر سازمان شما یک Domain داشته باشد و این دومین در چندین سایت فعالیت می کند بهتر است همه DCها نقش GC بر روی آنها فعال باشد.
ایجاد سایت برای هر یک از مناطق:
هر منطقه ای که شامل DC باشد یک سایت را تشکیل می دهد. برای ایجاد سایت:

    نام آن سایت را مشخص کنید.
    Subnetی به آن سایت اختصاص دهید.
    منطقه ای که شامل DC نباشد برای آن Siteی ایجاد نکنید.
    اتصال سایتها توسط Site linkها:

Replication بین سایتها بر اساس تنظیمات Site linkها اتفاق می افتد. شیء Site link نشان دهنده لینک ارتباطی می باشد که این سایت را به سایت دیگری متصل می کند. طبق مراحل زیر می توانید نحوه Replication بین سایتها را کنترول کنید:

    سایتها را توسط سایت لینکها (همانطور که در واقعیت هستند) به همدیگر وصل کنید.
    سایت لینکها بر اساس سایتهای که به همدیگر وصل می کنند نام گذاری کنید. مثلا Site-01-to-Site-02

تنظیم پارامترهای زیر برای سایت لینکها:

    Cost
    Schedule
    Interval


برای تعیین مقدار Cost هر یک از سایت لینکها:

    پهنای باند هر کدام از سایت لینکها را مشخص کنید.
    جدولی ایجاد کنید که شامل پهنای باند تمام Site linkها باشد.
 
مثلا اگر پهنای باند Site linkی 1Mbps باشد مقدار cost آن 340 می باشد.
نکته: اگر سایت لینکی اتصال آن مورد اطمینان نباشد مقدار Cost آن را بیشتر از بقیه ست کنید.

در مورد Schedule and Interval و مدت زمان Latency در مقالات قبلی توضیحات کافی دادم.
ظرفیت و گنجایش DCها:
پروسه های زیر باعث ایجاد Load بر روی DCها می شود:

    Logon کردن یوزرها و کامپیوترها.
    جستجوی دایرکتوری سرویس
    Replication
    رولهای FSMO
    و بقیه سرویسها که بر روی DC در حال اجرا می باشند.


پیش نیازهای سخت افزاری براساس رول ها و تعداد User ها برای DCها:

95 درصد از خطاهای که در پروسه کاری ما ادمین های شبکه بوجود می آید ناشی از رعایت نکردن Best Practice ها می باشد. اگر از اولین مرحله که همان طراحی شبکه می باشد طبق اصول و ضوابط پیش رویم احتمال مشکلات در آن محیط بصورت قابل توجهی کاهش می یابد. امیدوارم از این چند مقاله در بحث Replication که واقعا بحث اساسی و پایه شبکه های مایکروسافت می باشد بهره کافی را برده باشید.
منبع:
Best Practice Active Directory Design for Managing Windows Networks

https://msdn.microsoft.com/en-us/library/bb727085.aspx#EEAA

Active Directory Replication چگونه کار می کند قسمت دوم

پنج‌شنبه 15 تیر 1396 ساعت 11:48

    Replication بین چندین سایت برای انتقال Domain directory partition, زمانیکه DC های یک دومین در چندین سایت قرار دارند. همچنین اگر بیش از یک سایت داشته باشیم Replicate کردن Schema and configuration directory partition برای همه سایتها لازم و ضروری می باشد. Replication بین چند سایت از طریق Bridgehead server ها انجام می شود. هر سروری که یک Connection objet از DC های دیگر سایتها داشته باشید بعنوان Bridgehead server مشخص می شود. همچنین با دستور زیر می توانید Bridgehead server های هر سایت را مشخص کنید:

    repadmin /bridgeheads

    KCC دومین کنترولری را به عنوان Bridgehead انتخاب می کند که بتواند تمام Directory partition ها بعلاوه partial global catalog partitions را از دیگر سایتها Replicate کند. بصورت پیش فرض KCC بر روی DC ی که ISTG روی آن فعال باشد شروع به انتخاب Bridgehead server ها می کند. سرور های که نقش GC بر روی آنها فعال می باشد اولویت آنها برای BH زیادتر از بقیه DC ها می باشد.
    ترافیک Replicate شده بین سایتها فشرده سازی می شود.ولی این مسئله دورن یک سایت صدق نمی کند.
    بصورت پیش فرض همه سایت لینکها قابلیت تعدی یا Transitive هستند که این قابلیت را بصورت مفصل اینجا توضیح دادم.
    وقتی قابلیت Transitive بر روی همه site linkها فعال باشد KCC میتواند مسیر replicate را تعقیر دهد و connectionهای لازم را ایجاد کند.


    در صورت Down شدن BH سرورهای سایت Seattle پروسه KCC مسیر Replicate را تعقیر و کانکشنهای لازم با دو سایت Portland and Boston را ایجاد می کند.توجه کنید این پروسه در صورتی موثر می باشد که همه سایتها full route باشند و Transitive. پروسه KCC بوسیله مقدار Cost مسیر replication را تعیین می کند.
دو عدد سایت لینک که سه سایت را به همدیگر وصل کرده اند و قابلیت Transitive بر روی سایت لینکها فعال می باشد. برای اینکه سایت Portland and Boston بتوانند بصورت مستقیم با همدیگر Replicate کنند ISTG مقدار Cost دو سایت لینک را جمع می کند و حاصل آن می شود مقدار Cost لینک (مجازی یا منطقی) بین دو سایت Portland and Boston . در نتیجه DC3 یک Connection object با DC2 و بلعکس ایجاد می کند.
(اینجا را با دقت بخوانید و درک کنید)
ولی صبر کنید سه سایت بالا Directory Partition یکسانی دارند (همه DC ها در یک دومین فعالیت می کنند) پس در نتیجه ISTG بجای ایجاد یک Site link مجازی از سایت لینک PS که دارای Cost کمتری می باشد استفاده می کند و بوسیله متد Store-and-Forward بهره می برد و Replication را بوسیله DC های سایت Seattle ارسال و دریافت می کند. ولی اگر سایت Seattle دومین جداگانه ای باشد یا BH سرورهای سایت Seattle در دسترس نباشند یک Site link مجازی بین Portland and Boston ایجاد می شود.
نکته: تمام پروسه (ساختار را بصورت Full Route در نظر بگیرید) بالا در صورتی امکان پذیر می باشد که سایت لینکها Bridge or Transitive باشند.
نکته: برای اینکه پروسه بالا با موفقیت اجرا شود باید زمان بندی و دفعات Replication در دو سایت لینک PS and SB یکسان باشند.
نکته: اگر قابلیت Bridge بر روی این دو سایت لینک غیرفعال باشد هرگز سایت لینک مجازی بین سایتهای Portland and Boston ایجاد نمی شود. و شما باید یک Site link bridge بصورت دستی ایجاد کنید.
یک سوال خیلی مهم و کاربردی: چه زمانی ما باید یک Site link bridge بصورت دستی ایجاد کنیم؟؟؟
زمانی که ساختار ما non-full route باشند و Domain directory partition مربوط به یک دومین در چند سایت مختلف نگهداری می شود. به عبارت دیگر DC های یک دومین در چند سایت مختلف می باشند.
بریم سراغ نحوه عملکرد پروسه KCC:

    پروسه KCC هر 15 دقیقه کل توپولوژی را چک می کند و توپولوژی مورد نظر را ایجاد یا تعقیر می دهد.
    بصورت پیش فرض اولین فعالیت KCC 5 دقیقه بعد از استارت شدن DC می باشد. اگر DC دارای سرویس های DHCP-WINS و غیره باشد این مدت زمان افزایش می یابد. این مدت زمان از طریق Registry قابل تعقیر می باشد.

KCC در دو مرحله توپولوژی را ایجاد می کند:
Evaluation:در این فاز KCC با استفاده از اطلاعات موجود در DC ساختار را ارزشیابی می کند و طبق این اطلاعات Connection object ها را ایجاد یا حذف می کند.
Translation: در این فاز طبق ارزشیابی وتصمیماتی که KCC در مرحله قبلی انجام داده توپولوژی را ایجاد می کند. در این مرحله KCC یک صفت RepsFrom برای هر DC ایجاد می کند که برای Intra-site topology لازم می باشد یا بر روی Bridgehead server ها این صفت را ایجاد می کند. (برای Inter-site topology)
محدوده و مدهای فعالیت KCC:

وقتی KCC توپولوژی را محاسبه میکند دو نوع replication را لحاظ می کند یکی Writable or read-only Replication که برای هر کدام از آنها قوانینی وجود دارد:

    writable replica بروزرسانی ها را فقط از writable replica دریافت می کند.
    Read-only replica می تواند بروز رسانیها را از writable replica دریافت کند.
    Read-only replica همچنین می تواند ابدیتها را از Read-only replica دریافت کند.
    writable replica هرگز بروزرسانیها را از یک Read-only replica دریافت نمی کند.

KCC برای هر یک از Directory partition ها دو نوع توپولوژی محاسبه می کند. یکی برای Writable replica و یکی برای read-only replica. که این محاسبات تحت شرایطی منجر به ایجاد یک Connection object اضافی برای read-only replica می شود.
شاید بعضیا تفاوت این دو مد را با هم ندانند که توضیح میدم. بعضی از Directory partition ها بصورت کامل بین DC های یک فارست Replicate می شود مانند Schema, configuration و هر یک از DC ها سه نوع پارتیشن را بصورت کامل دریافت می کنندSchema, configuration و Domain partition مربوط به دومین خود (دومین معتبر) به این نوع ریپلیکیشن Writable replica می گویند. در بعضی از DC ها نقش GC فعال می باشد GC علاوه بر پارتیشن های بالا نیاز به Domain directory partition بقیه دومین های فارست دارد. ( GC تمام اطلاعات Domain partition بقیه دومین ها را دریافت نمی کند بلکه Attribute های محدودی از همه ابجکتها را (که در Schema قابل تعیین می باشد که به لیست PAS معروفه) دریافت می کند که به این نوع Replication بین دو GC میگن Read-only Replica. همچنین پارتیشنی که بین GC ها Replicate می شود Read-only می باشد. در تصویر زیر یک سایت با چهار دومین مختلف مشاهده می کنید. بر روی یکی از DC های دومین A نقش GC فعال می باشد. Replicate بین DC ها بدین شکل می باشد:

نکته مهم: اگر یک DC بعد از چند با سعی کردن نتوانست جوابی از DC مقابل دریافت کند و این روال تا دو ساعت همچنان باقی بماند KCC فرض را بر غیر قابل دسترس بودن این DC میگذارد. و توپولوژی را دوباره محاسبه می کند و Connection object آن DC را پاک و یک Connection object جدید ایجاد و یک DC جدید انتخاب می کند.

    Replication برای ارتباط در یک یا چندین سایت بصورت پیش فرض از RPC استفاده می کند. RPC برای عملکرد خود از پورتهای تصادفی استفاده می کند. در جدول زیر پورتهای لازم برای Replication را می بینید:


در سناریوهای که بین کلاینتها و DC فایروالی وجود دارد شما باید این پورتها را در مد Fixed تنظیم کنید. برای اینکار از گوگل استفاده کنید.
در این مقاله روش ایجاد توپولوژی در Intra-site and Inter-site را بصورت مفصل توضیح ندادم (گرچه در مقاله های آتی به آن اشاره خواهم کرد) ولی شما می توانید این قسمتها را در لینک زیر مطالعه کنید.

Active Directory Replication Topology چگونه کار می کند قسمت اول

پنج‌شنبه 15 تیر 1396 ساعت 11:44
اینبار بصورت کاملا متفاوت می خواهیم این پروسه جذاب وپیچیده را با هم یاد بگیریم.

    برای انتقال داده ها درون یک دومین یا یک فارست و همچنین Sync کردن پارتیشن های Forest-wide در یک فارست اکتیو دایرکتوری از Replication استفاده می کند.
    برای اینکه پروسه Replication بتواند این اطلاعات را بصورت بهینه دورن یک سایت یا بین سایتها منتقل کند یک توپولوژی ایجاد می کند.
    Replication topology توسط KCC یا Knowledge Consistency Checker بر روی یک Domain Controller ایجاد می شود.
    KCC برنامه ای می باشد که شامل اجزای مختلفی هستش و بر روی هر یک از DC ها عمل می کند. کانفیگ و مدیریت Replication توسط KCC انجام می شود.
    KCC بصورت جداگانه بر روی DC ها فعالیت می کنند و هیچ ارتباطی با دیگر DC ها ندارند. در نتیجه آنها باید از یک الگوریتم ثابت و به همراه داده های که در Schema and * Configuration Partition ذخیره شده است استفاده کنند و توپولوژِی خود را ایجاد کنند.
    برای اینکه KCC بتواند Replication topology را ایجاد کند از اطلاعات ساختار اکتیودایرکتوری استفاده میکند. این اطلاعات را از پارامترهای زیر بدست می آورد:
        سایت
        سرورها
        سایتهای وابسته به هر یک از سرورها
        گلوبال کاتالوگ
        Directory partition های ذخیره شده بر روی سرور
        سایت لینک ها
        Site link Bridge
    برای اینکه KCC بتواند از اطلاعات ذخیره شده بر روی هارد دیسک DC و پارتیشنهای دایرکتوری سرویس استفاده کند از Directory System Agent استفاده می کند. DSA دسترسی KCC به اطلاعات مهم برای ساختن Replication topology را مسیر می کند.
    KCC می تواند برای ایجاد Replication topology داده های (مربوط به Replication) را ایجاد، تعقیر یا حذف کند.
    KCC در صورتی با دیگر DC ها ارتباط برقرار می کند که به دنبال Replication error باشند. KCC از این پروسه برای عیب یابی Replication استفاده می کند. یادتون باشه Replication error فقط درون یک سایت اتفاق می افتد.
    KCC برای ارتباطات خود از پروتکل RPC استفاده می کند نه پروتکل LDAP
    برای اینکه ترافیک Replication بین DCهای یک سایت یا چندین سایت جریان داشته باشد KCC و ISTG کانکشن ایجاد می کنند. این کانکشنها را Connection object می نامند.
    قبل از اینکه Connection object ها ایجاد شوند باید DC مبدا و DC مقصد مشخص شود. بعد از مشخص شدن این دو پارامتر Connection objectها ایجاد خواهند شد.
    یکی از اجزای KCC که خیلی هم مهم می باشد ISTG یا Intersite Topology Generator نام دارد که وظیفه آن ایجاد connection object های مناسب بین Bridgehead server ها برای ایجاد Replication بین سایتها می باشد. ISTG علاوه بر وظیفه فوق وظیفه انتخاب Bridgehead server و مدیریت Replication بین سایتها را بر عهده دارد.
    Bridgehead server ها نمایندگان هر سایت می باشند که وظیفه Replication کردن تعقیرات سایت با سایتهای دیگر می باشد و همچنین تعقیرات ایجاد شده توسط سایتهای دیگر را دریافت می کنند و به DC های سایت خود منتقل می کنند.
    ISTG فقط بر روی یکی از DC ها در کل سایت اجرا خواهد شد و یک دید کلی از کل DC های درون یک Forest را ایجاد می کند.
    محدوده فعالیت KCC فقط بر روی یک DC می باشد ولی محدوده عملکرد ISTG کل یک سایت.


    بصورت خیلی ساده و خلاصه شده ESE جدولی می باشد که روند عملکرد یک سرویس را ردیابی می کند و بصورت Log file این رویدادها را در دیتابیس خود ذخیره می کند.
    در تصویر بالا چهار DC مشاهده می کنید که چون همه از یک الگوریتم و یک پارتیشن سراسری (Configuration Directory Partition) استفاده می کنند یک Topology کلی برای خود ایجاد کرده اند.
    DC های که Intrasite Replication Topology را ایجاد می کنند همیشه خود را به عنوان DC های مبدا ست می کنند. و DC های دیگر DC های مقصد ترافیک Replicate را از DC های مبدا درخواست می کنند.

دو نوع Topology داریم:

    Intra-site topology
    Inter-site topology

    به Replication ی که درون یک سایت انجام می شود Intra-site replication می گویند. و Replicationی که بین سایتها اتفاق می افتد را Inter-site replication می نامند. replication topology درون یک سایت توسط KCC ایجاد می شود. و Inter-site topology توسط ISTG ایجاد می شود.
    KCC توپولوژی درون یک سایت را همیشه بصورت Ring ایجاد می کند. و ISTG یک دید کلی از کل Bridgehead Server های سایتهای دیگر ایجاد میکند.



بعضی از اجزای KCC برای اجرای Replication موفقیت امیز، ضروری هستن بعضی از انها ضروری نیستند و فقط برای بهینه سازی این ارتباط بکار می روند.
    در تصویر بالا همه ی سرورها Domain controller هستند. همه ی آنها بصورت مستقل از اطلاعات دایرکتوری سرویس استفاده می کنند و Connection object های خود را ایجاد می کنند. KCC توپولوژی Intra-site را بین DC های یک سایت ایجاد می کند. و ISTG توپولوژی بین سایتها را نیز ایجاد می کند. درون یک سایت همه DC ها بصورت Ring تعقیرات خود را Replicate می کنند. و ISTG توپولوژی Inter-site را توسط Bridgehead Server ها ایجاد میکند.
    هر سایت در تصویر بالا نمایانگر محدوده فعالیت فیزیکی یک شبکه یا یک شعبه از یک کمپانی بزرگ می باشد که در آنها ارتباطات سرویس ها با یکدیگر حداقل با سرعت 10 Mbps می باشد. ما این محدوده را توسط شیء به نام Siteدر ساختار دایرکتوری سرویس ایجاد می کنیم. ما این سایتها را توسط یک ارتباط پر سرعت مانند Wireless یا MPLS با هم دیگر وصل می کنیم. در ساختار دایرکتوری ما این لینک ارتباطی را بوسیله شیء به نام Site link مشخص می کنیم. Site link ها به Bridgehead server هر سایت اجازه ارتباط با دیگر Bridgehead server ها را می دهد.
    Replication بین سایتها توسط پروتکل RPC انجام می شود. همچنین این پروتکل داخل یک سایت هم استفاده می شود. در تصویر بالا مشاهده می کنید که لینک ارتباطی بین سایت A and D پروتکل SMTP می باشد این پروتکل مانند پروتکل RPC برای Replicate کردن:
        Configuration Directory Partition
        Schema Directory Partition
        Global Catalog read-only, partial
        read-only directory partitions
    استفاده می شود.این پروتکل برای Replication کردن writable domain directory partitions,ها استفاده نمی شود. این پروتکل برای مواقعی استفاده می شود که ارتباط TCP/IPبا سایت مقصد وجود نداشته باشد یا Site link قابل اعتماد نمی باشد.
    بصورت پیش فرض Site link A-B and A-C بصورت transitive هستند (bridged) بدین معنی که بدون Site link بین سایت B and C ترافیک Replicationبین این دو سایت از طریق سایت A جریان دارد. هر Site link یک پارمتر به نام Cost دارد که ISTG از این پارامتر برای تعین بهترین مسیر برای Replication استفاده می کند. در تصویر بالا مقدار Cost که بر روی Site link A-B and A-C وجود دارد با هم دیگر جمع می شوند و حاصل آن بعنوان یک مسیر ترجیح داده شده برای سایتهای B and C تلقی می شود. در نتیجه Replication بین سایت B and C بصورت اتوماتیک از طریق سایت A به همدیگر Route می شود. در صورتی این دو سایت با هم دیگر بصورت مستقیم Replicate می کنند (با ایجاد Connection object) که Bridgehead server های سایت A در دسترسی نباشند یا متعلق به دومین دیگری باشد.

KCC به منظور اهداف زیر Replication topology را ایجاد می کند:

    متصل کردن Directory Partition های یکسان و سینک کردن انها.
    کنترول زمان تاخیر Replication بین سایتها
    مسیر Replication بین سایتها.
    بهبود در Log on کردن کلاینتها.

    بصورت پیش فرض Replication Topology بصورت اتوماتیک توسط KCC and ISTG ایجاد می شود. ولی ادمین می تواند آن را بصورت دستی ایجاد کند یا تعقیر دهد که اولویت با تعقیرات ایجاد شده توسط ادمین می باشد.
    یک Replication topology در واقع شامل چندین Replication topology اساسی می باشد. این توپولوژی ها بر اساس Directory partition ها ساخته می شوند. مثلا Schema and Configuration directory partition از یک توپولوژی استفاده می کنند و Application directory partition از یک توپولوژی جداگانه. و همچنین Domain directory partition از یک توپولوژی جداگانه. بعضی از این توپولوژی ها با هم دیگر ادغام می شوند و از کانالهای ارتباطی (connection object) استفاده می کنند و با تمام DC های که داده های یکسانی را نگهداری می کنند Replicate می شوند. به عنوان مثال Configuration and Schema directory partition بر روی همه DC های Forest یکسان می باشد.

نکته: اگر Domain controller ها Replica ی هم دیگر هستند (DC های یک دومین) برای Replication کردن Directory partitionها از یک Connection object استفاده می شود.
همانطور که اشاره کردیم برای هر یک (یا هر چند) از Directory partition ها یک توپولوژی متفاوت ایجاد می شود. در بعضی از حالات Schema and Configuration Directory partition و Application Partition از همان توپولوژی استفاده می کنند که Domain directory partition استفاده می کند.
نکته: در شرایطی که Application and domain directory partition در DC مبدا و DC مقصد یکسان باشند KCC برای Application partition یک Connection object جداگانه ای ایجاد نمی کند.
حتما به این نتیجه رسیدید که Connection object ها بر اساس Topology ها ایجاد می شوند. افرین به شما که به نتیجه درستی رسیدید.
نکته: هرگز برای partial replicas که در Global catalog ذخیره می شوند توپولوژی جداگانه ای ایجاد نمی شود. در نتیجه GC از Connection object های توپولوزی های دیگر استفاده می کند.
برای اینکه KCC یا ISTG بتواند توپولوژی یا توپولوژی های نهائی را ایجاد کند مسیرهای ارتباطی directory partition های زیر را جمع بندی می کند:

    Configuration and schema within a site.
    Each writable domain directory partition within a site.
    Each application directory partition within a site.
    Global catalog read-only, partial domain directory partitions within a site.
    Configuration and schema between sites.
    Each writable domain directory partition between sites.
    Each application directory partition between sites.
    Global catalog read-only, partial domain directory partitions between sites.

قضیه تاخیر یا Latency بین سایتها را می توانید در این مقاله مطالعه کنید.
همچنین بهبود در Log on کردن کلاینتها را میتوانید اینجا مطالعه کنید.
اکتیودایرکتوری اطلاعات مربوط به Replication topology را در Configuration directory partition ذخیره می کند.
برای اینکه KCC و ISTG بتوانند بهترین ومتناسبترین توپولوژِی ساختار دایرکتوری سرویس را ایجاد کنند نیاز به کمک شما دارند. عاره شما دوست عزیز :) بعضی از پارامترها را باید به این دو پروسه معرفی کنید تا بدونن چطور توپولوژی را ایجاد کنند. مایکروسافت کنسول AD Site and Services را برای این منظور ایجاد کرده است.
Image

    شیء Site در کنسول بالا نشان دهنده یک یا چند Subnet می باشد که درون یک سایت استفاده می شوند ، زیر مجموعه Site کانتینری به نام Server وجود دارد که DC های آن سایت را مشخص می کند.
    شیء Subnet سگمنتهای TCP/IP می باشند که به کلاینتهای آن سایت تعلق دارد. همچنین از این شیء برای مشخص کردن محدوده فعالیت کلاینتها استفاده میشود. ادرس هر کلاینت نماینگر سایت آن کلاینت می باشد.
    شیء Subnet به شیء Site مپ می شود. در پروسه Domain controller location کلاینتها از شیء Subnet and Site استفاده می کنند و DC های آن سایت یا سایت نزدیک را پیدا می کنند.
    بصورت پیش فرض وقتی Active Directory را نصب می کنید هیچگونه Subnetی ایجاد نمی شود و اگر در یک ساختار چندین سایت داشته باشید و Subnetی تنظیم نکنید پروسه احراز هویت و استفاده از منابع شبکه با مشکل رو به رو می شود.
    زیر مجموعه سایت شیء به نام Server وجود دارد که DC های یک سایت در آن نگهداری می شود. هنگام نصب Domain Controller تنظیمات IP آن با سایتها و سابنتها مقایسه می شود و بصورت اتوماتیک، DC سایت خود را در هنگام نصب انتخاب میکند. ولی اگر تنظیمات IP سرور DC با هیچکدام از سایتها مچ نباشد خود را در سایت DCی عضو می کند که اولین Replication را با آن انجام دهد.
    وقتی شما DC ی از سایتی به سایت دیگری منتقل می کنید باید تنظیمات IP آن را مطابق آن سایت بصورت دستی تعقیر دهید. و دستورات زیر را بر روی آن اجرا کنید:

    Ipconfig /flushdns

    Ipconfig /registerdns

    Net stop netlogon

    Net start netlogon

    و همیشه در قسمت Preferred dns server ادرسها را بصورت ضربدری بر روی DC ها تنظیم کنید. علت اینکار را در اینده اگر عمری باقی ماند توضیح می دهم.
    شیء NTDS که زیر مجموعه Server می باشد نشان دهنده آن است که بر روی این سرور سرویس Active Directory نصب می باشد. و همچنین این شیء نشان دهنده DC های در حال کار و یا از رده خارج شده می باشد.
    وقتی شما DCی را demote می کنید شی NTDS حذف می شود. تا نشان دهد این سرور از رده خارج می باشد.
    Connection object شیء می باشد که برای Replication بین DC ها استفاده می شود. Connection object یک مسیر یک طرفه می باشد که DC های مبدا ترافیک Replication خود را به سمت آنها (DC های مقصد) ارسال می کنند.
    KCC برای هر DC ی که دارای شیء NTDS باشد یک Connection object می سازد. (این پروسه برای DC های درون یک سایت اتفاق می افتد)

Connection object هم بصورت یک طرفه One-way و هم دو طرفه Two-way در ارتباط می باشد. متد One-way درون یک سایت کاربرد دارد ولی متد Two-way بین سایتها استفاده می شود. مثال می زنم: وقتی چندین سایت داشته باشیم و قابلیت Bridge link را غیرفعال کنیم ISTG یک Connection object می سازد و از طریق این کانکشن ترافیک replication را دریافت و ارسال می کند.

    بحثی داریم به نام مالکیت Connection object یا Ownership of Connection Objects کانکشنهای که توسط KCC ایجاد می شوند در مالکیت KCC قرار دارند و KCC میتواند آنها را حذف، تعقیر یا ایجاد کند. ولی اگر ادمین یک کانکشن ایجاد کند این کانکشن در مالکیت ادمین می باشد و پروسه KCC حق ندارد آن را تعقیر دهد.
    وقتی شما کانکشنی را که در مالکیت KCC or ISTG باشد تنظیمات آن را تعقیر دهید از مالکیت KCC خارج می شود.
    وقتی ادمین کانکشنی را ایجاد می کند، ان کانکشن باقی می ماند تا ادمین ان را پاک کند. همچنین اگر KCC کانکشنهای یکسانی را ایجاد کند انها را بصورت اتوماتیک حذف خواهد کرد و فقط کانکشنهای ضروری را ایجاد می کند.
    DC ها همیشه کانکشنهای DC های مبدا را در خود ایجاد می کنند و replication را از آنها درخواست می دهند.

Image

    برای اینکه ISTG بتواند Connection object های لازم بین سایت خود با سایتهای دیگر را ایجاد کند نیاز به ایجاد یک Site Link می باشیم. شیء Site Link به پروتکل انتقال ترافیک Replication و زمانبندی کردن Replication بین سایتها و همچنین لینک اتصال دو سایت اشاره دارد. ISTG از اطلاعات ذخیره شده در Site Link ها استفاده و Inter-site topology را ایجاد میکند.
    بصورت پیش فرض همه site linkها که از یک پروتکل انتقال (IP or SMTP) استفاده می کنند، KCC فرض می کند که همه آنها بوسیله یک مسیر یا Route به همدیگر وصل (bridge) می باشند. اگر می خواهید KCC چنین برداشتی نکند و برای دسترسی به سایتی چندین مسیر وجود دارد یا در مواقعی که سایتهای شما Full route نباشند باید این قابلیت را غیرفعال کنید و Route های مختلفی بوسیله Site link bridge بصورت دستی ایجاد و Site link ها را عضو Site link bridge کنید.
    NTDS Site Settings Object شیء می باشد که در زیر مجموعه سایت قرار دارد و تنظیمات و نحوه اعمال این تنظیمات بصورت Site-wide می باشد. هر سایت مجاز به داشتن یک NTDS Site Settings Object می باشد:

Image

NTDS Site Settings Object هر سایت وظایف زیر را بر عهده دارد:

    مشخص کردن ISTG هر سایت.در تصویر بالا BF-01-DC مسئنول و مالک این پروسه در این سایت می باشد.
    ایا DC های این سایت مجاز به کش کردن اعضای Universal groups هستند یا نه؟
    ایجاد زمان بندی برای Connection object ها.

    شیء دیگری وجود دارد به نام Cross-Reference Objects که در کنسول AD Site and Services قابل مشاهده نیست و بوسیله کنسول Adsiedit.msc قابل مشاهده می باشد. این شیء محل های Directory Partition را ذخیره می کند. Active directory replication از این شیء استفاده می کند و DC های که Directory Partition بر روی انها ذخیره شده است را نشان می دهد.
    DC برای انتقال Replication از دو پروتکل انتقال استفاده می کند: RPC over IP and STMP over IP. Replication درون یک سایت و بین سایتها همیشه از RPC over IP بصورت همزمان استفاده می کند. برای سایتهای که به ندرت در دسترس هستند و ارتباط درست و درمونی بین آنها نباشه از SMTP over IP استفاده می شود. توجه کنید SMTP برای انتقال Replication بین یک Domain در دو سایت مختلف استفاده نمی شود چون بوسیله این پروتکل فقط پارتیشنهای زیر Replicate می شود:
        Schema
        Configuration
        Global catalog

در نتیجه Domain partition نمی تواند از SMTP استفاده کند.
SMTP and IP از دو متد برای انتقال ترافیک Replication استفاده می کنند.

    Synchronous=RPC over IP
    Asynchronous=SMTP over IP

    RPC over IP از Synchronous استفاده و شروع به Inbound Replication می کند. در ارتباطات Synchronous دومین کنترولر مقصد درخواست Replicate با DC مبدا می کند و منتظر جواب می ماند تا DC مبدا درخواست را دریافت کند و Replication را اماده کند و ان را قبل از ارسال notification change به بقیه DC آن را به سمت DC مقصد ارسال کند. به این پروسه inbound replication می گویند در نتیجه DC ها مقصد در ارتباطات Synchronous جواب و داده های Replication را در مدت زمان کوتاهی دریافت می کنند. پروتکل IP از متد Synchronous استفاده می کند. ولی در متد Asynchronous که برای پروتکل SMTP استفاده می شود DC های مقصد منتظر جواب DC های مبدا نمی مانند و در بازه های زمانی خاص درخواست Replication را به چندین DC ارسال می کنند. در نتیجه دریافت Replication در یک زمان کوتاه اتفاق نمی افتد.
    اگر سایت شما در نقطه بدی قرار دارد و همیشه در دسترس نباشد و نتوان بوسیله RPC over IP اطلاعات Replicate را سینک کرد، تنها گذینه ای که برای Replication بین دو سایت باقی می ماند استفاده از E-Mail می باشد. وقتی که ارتباط دو سایت با هم دیگر قطع وصل می شود باید از روش Asynchronous استفاده کرد (SMTP) به علاوه زمانی که محدودیتی از نظر پهنای باند بین دو سایت داشته باشیم نمی توان دو DC را مجبور کرد تمام اطلاعات خود را (All directory partition) ریپلیکت کنند در نتیجه می توان از SMTP استفاده کرد که درخواست خود را در بازه های زمانی مختلفی برای چند DC ارسال کند و در هر بازه از زمان قسمتی از اطلاعات را دریافت کند.
    در Inter-site replication و استفاده از SMTP ما بجای RPC از Mail messaging استفاده می کنیم. در این روش از Change notification استفاده نمی شود بلکه هنگامی که هر دو سایت به همدیگر وصل شدند شروع به تبادل اطلاعات می کنند.
    Intersite messaging قابلیتی می باشد برای Replication بین دو DC که از SMTP استفاده می کنند. این قابلیت هنگام نصب سرویس AD نصب و فعال می شود.
    KCC برای DC های که از SMTP استفاده می کنند Connection object ایجاد نمی کند تا وقتی که شرایط زیر بر روی DC ها اعمال شود:
        باید رول IIS را بر روی هر دو Bridgehead server ها نصب کنیم
        نصب CA در مد Enterprise برای رمزگذاری پیغامهای ردو بدل شده بین دو سایت. وجود Domain Controller Certificate بر روی CA Server ضروری می باشد.
        دوسایت باید بوسیله SMTP site link به همدیگر وصل باشند.
        اگر دو سایت را بوسیله چندین Site link وصل کرده باشید (IP or SMTP) باید site link مربوط به SMTP کمترین مقدار Cost را داشته باشد.

سایتهای که مربوط به یک Domain باشند. کلا نمی توانند از این روش استفاده کنند.

    DC را باید تنظیم کنیم که E-Mail ها را دریافت کند، علاوه بر آن باید مطمئن شد که mail ها دست DC مقابل برسد. (اگر دو سایت مستقیما به هم دیگر وصل باشند نیازی به تنظیم خاصی نیست، در غیر اینصورت نیاز به تنظیم یک Mail gateway هستیم.

( تعداد کل: 12 )
   1       2       3    >>