اکتیو دایرکتوری (AD DS) سرویس دایرکتوری مایکروسافت برای مدیریت متمرکز حساب کاربران، کامپیوترها، گروه‌ها و دسترسی‌هاست. برنامه‌ها و منابعی که با دامین یکپارچه شده‌اند می‌توانند از هویت مشترک استفاده کنند. تغییر یا غیرفعال‌کردن حساب، مدیریت دسترسی را متمرکز می‌کند؛ بااین‌حال پایان نشست‌ها و بلیت‌های قبلی ممکن است کنترل جداگانه لازم داشته باشد و قطع فوری همهٔ دسترسی‌ها تضمین نمی‌شود.
تا وقتی شرکت چند کامپیوتر دارد، حساب محلی روی هر دستگاه کار را راه می اندازد. از جایی که کامپیوترها به ده ها عدد می رسند، تغییر رمز، اضافه کردن کاربر جدید یا گرفتن دسترسی یک نفر یعنی سر زدن به تک تک دستگاه ها. اکتیو دایرکتوری همین مدیریت پراکنده را متمرکز می کند.
اجزای اکتیو دایرکتوری
| اصطلاح | معنی |
|---|---|
| دامین (Domain) | مرز مدیریتی که کاربران و کامپیوترهای شرکت داخل آن تعریف می شوند، مثل corp.example.com |
| دامین کنترلر (DC) | سروری که نسخه ای از پایگاه داده اکتیو دایرکتوری را دارد و درخواست های ورود را تأیید می کند |
| فارست (Forest) | مجموعه یک یا چند دامین که یک ساختار و یک schema مشترک دارند |
| OU (Organizational Unit) | پوشه ای برای دسته بندی کاربران و کامپیوترها، مثلاً به تفکیک واحدها یا شعبه ها |
| Group Policy (GPO) | مجموعه تنظیماتی که روی OU یا کل دامین اعمال می شود |
| Global Catalog | فهرست جستجوی سریع از همه اشیای فارست که برنامه هایی مثل Exchange به آن نیاز دارند |
دامین کنترلر چه کاری می کند
دامین کنترلر سرویس AD DS را اجرا می‌کند و در احراز هویت و اعمال سیاست‌های دامین نقش دارد. Kerberos از تبادل پیام‌های رمزنگاری‌شده و بلیت استفاده می‌کند؛ ورود به دامین به معنای ارسال سادهٔ رمز عبور به سرور در هر بار ورود نیست. استفاده از NTLM به سازگاری برنامه و تنظیمات محیط بستگی دارد. در صورت فعال‌بودن cached logon، کاربری که قبلاً وارد همان دستگاه شده ممکن است هنگام قطع ارتباط با DC بتواند وارد ویندوز شود؛ این ورود محلی، دسترسی به منابع نیازمند اعتبارسنجی دامین را تضمین نمی‌کند.
یک دامین می‌تواند با یک دامین‌کنترلر کار کند؛ برای کاهش نقطهٔ تک‌خرابی، معمولاً بیش از یک DC در بسترهای مستقل طراحی می‌شود. تعداد و محل DCها به اندازه، شعبه‌ها و نیاز بازیابی وابسته است. تغییرات با replication میان DCهای قابل‌نوشتن منتقل می‌شوند. فرمان‌های زیر برای بررسی وضعیت‌اند و به‌تنهایی سلامت کل دامین را اثبات نمی‌کنند:
repadmin /replsummary
dcdiag /vGroup Policy برای چه چیزی خوب است
با Group Policy می شود تنظیمات را یک بار نوشت و روی صدها کامپیوتر اعمال کرد. کاربردهای رایجش در شرکت ها:
- سیاست رمز عبور و قفل شدن حساب بعد از چند تلاش ناموفق
- وصل شدن خودکار پوشه های اشتراکی و چاپگرها به کاربر مناسب
- نصب نرم افزار و تنظیم مرورگر برای همه کامپیوترهای یک واحد
- بستن USB، فعال کردن فایروال ویندوز و روشن بودن به روزرسانی خودکار
- اجرای اسکریپت هنگام ورود یا خاموش شدن کامپیوتر
هر GPO باید هدف، دامنهٔ اعمال و روش آزمون روشن داشته باشد. سیاست رمز و قفل حساب‌های دامین در سطح دامین تنظیم می‌شود؛ برای سیاست‌های متفاوت کاربران یا گروه‌های مجاز، Fine-Grained Password Policies کاربرد دارد. لینک‌کردن یک GPO معمولی به OU، جایگزین این سازوکار برای حساب‌های دامین نیست. سایر تنظیمات را متناسب با site، domain یا OU و با بررسی filtering و precedence اعمال کنید.
نقش های FSMO
بیشتر کارهای اکتیو دایرکتوری روی هر دامین کنترلری انجام می شود، ولی پنج کار فقط یک مجری دارند. به آن ها نقش های FSMO می گویند:
- Schema Master و Domain Naming Master: یکی برای کل فارست، مسئول تغییر ساختار و اضافه کردن دامین
- PDC Emulator: در هر دامین یک دارنده دارد و تغییرات رمز از DCهای دیگر با اولویت به آن تکثیر می‌شود. PDC دامین ریشهٔ فارست معمولاً بالای سلسله‌مراتب زمان قرار دارد.
- RID Master: به هر دامین کنترلر بازه ای از شناسه ها می دهد تا اشیای جدید شناسه تکراری نگیرند
- Infrastructure Master: ارجاع بین دامین ها را به روز نگه می دارد
در یک محیط تک‌دامینی ممکن است چند نقش روی یک DC قرار داشته باشند؛ محل مناسب نقش‌ها به طراحی و بار بستگی دارد. برای بازنشسته‌کردن یا خروج طولانی‌مدت دارندهٔ نقش، انتقال نقش‌های مربوط را برنامه‌ریزی کنید؛ restart معمولی الزام انتقال همهٔ نقش‌ها نیست. دارندهٔ نقش‌ها را با فرمان زیر مشاهده کنید:
netdom query fsmoوابستگی به DNS و ساعت
DNS و هماهنگی زمان دو وابستگی مهم برای کشف DC و احراز هویت هستند؛ خطای ورود می‌تواند علت‌های دیگری هم داشته باشد.
کلاینت‌ها DC را با رکوردهای SRV پیدا می‌کنند. DNS تنظیم‌شده باید zone و رکوردهای AD را به‌درستی resolve کند؛ الزاماً همهٔ دستگاه‌ها یک آدرس DNS یکسان ندارند. resolver عمومی معمولاً رکوردهای خصوصی دامین را نمی‌شناسد. تنظیم DNS داخلی، forwarding و مسیر دسترسی را متناسب با طراحی شبکه بررسی کنید.
Kerberos به اختلاف ساعت محدود وابسته است؛ تحمل پیش‌فرض معمولاً پنج دقیقه است و سیاست محیط باید بررسی شود. اعضا و DCها زمان را در سلسله‌مراتب دامین هماهنگ می‌کنند. PDC دامین ریشهٔ فارست معمولاً از منبع معتبر بیرونی یا مرجع زمانِ طراحی‌شده تغذیه می‌شود؛ همهٔ دستگاه‌ها مستقیماً از یک PDC زمان نمی‌گیرند.
اشتباه های رایج در راه اندازی دامین کنترلر
- اتکا به یک DC، نقطهٔ تک‌خرابی ایجاد می‌کند. خرابی آن می‌تواند احراز هویت تازه و سرویس‌های وابسته را مختل کند، هرچند ورود محلیِ کش‌شده در برخی دستگاه‌ها ممکن است ادامه پیدا کند.
- نام دامین به صورت corp.local انتخاب می شود. پسوند local با سیستم هایی مثل mDNS تداخل می کند و برای ایمیل و گواهی ها هم دردسر دارد. زیردامینی از دامنه ثبت شده شرکت (مثلاً ad.example.com) انتخاب بهتری است.
- روی دامین کنترلر برنامه های دیگر نصب می شود. هر برنامه اضافه سطح حمله را بالا می برد، و دامین کنترلر هدف اصلی مهاجم است.
- مدیر شبکه برای کار روزمره با حساب Domain Admin وارد می شود. برای کار عادی یک حساب معمولی و برای کار مدیریتی حساب جدا بسازید.
- نبود بکاپ معتبر و روش بازیابی آزموده‌شده، بازیابی دامین یا فارست را دشوار می‌کند. نوع بکاپ، سازگاری نسخه، دسترسی به رمز بازیابی و نسخهٔ مستقل باید طبق راهنمای بازیابی AD بررسی شوند.
- Snapshot جایگزین بکاپ و برنامهٔ بازیابی نیست. Windows Server 2012 و جدیدتر در هایپروایزر دارای VM-GenerationID سازوکارهای حفاظتی دارند؛ سازگاری هر دو طرف، replication و احتمال ازدست‌رفتن تغییرات پس از snapshot باید بررسی شود. روش نسخهٔ مشخص را از مستندات Microsoft دنبال کنید.
نصب سریع و بررسی بعد از آن
نمونهٔ زیر برای ساخت فارست تازه در محیط آزمایشیِ مستقل است؛ آن را برای افزودن DC به دامین موجود اجرا نکنید. پیش از اجرا باید نسخهٔ پشتیبانی‌شده، نام دامنه، IP و DNS، دسترسی مدیریتی و مسیر بازیابی مشخص باشند. نصب AD DS و ارتقا به DC تغییر عملیاتی است؛ فرمان دوم رمز DSRM می‌خواهد و می‌تواند سرور را راه‌اندازی مجدد کند:
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName "ad.example.com"پس از راه‌اندازی مجدد، نتیجهٔ dcdiag و رخدادها، رکوردهای SRV، اتصال یک کلاینت آزمایشی و ورود کاربر عادی را بررسی کنید. برای بکاپ، ابتدا مقصد مستقل و قابل دسترس و روش بازیابی را مشخص کنید. حرف E: در فرمان زیر فقط مثال است؛ وجود درایو یا معتبر بودن بکاپ را تضمین نمی‌کند. قابلیت Windows Server Backup و فضای کافی لازم است و بازیابی باید جداگانه آزمایش شود:
wbadmin start systemstatebackup -backuptarget:E:اگر کامپیوتر نمی تواند وارد دامین شود
برای مشکل ورود، ابتدا پیام خطا و وضعیت حساب و دستگاه را ثبت کنید. موارد زیر چند مسیر بررسی‌اند، نه فهرست کامل علت‌ها:
- DNS تنظیم‌شده ممکن است رکوردهای AD را resolve نکند. با
nslookup -type=SRV _ldap._tcp.dc._msdcs.ad.example.comو نام واقعی دامین خود، پاسخ SRV و دسترسی به مقصد را بررسی کنید؛ resolver الزاماً خود DC نیست. - ساعت کامپیوتر با دامین کنترلر بیش از حد مجاز اختلاف دارد. با
w32tm /query /statusمنبع زمان و آخرین همگام سازی را ببینید. - محدودیت شبکه می‌تواند کشف DC، احراز هویت یا replication را مختل کند. پورت، پروتکل و جهت ترافیک به سناریو بستگی دارد؛ علاوه بر سرویس‌های DNS/Kerberos/LDAP/SMB، زمان از UDP123 و برخی عملیات از RPC پویا، معمولاً TCP49152–65535، استفاده می‌کنند. جدول رسمی فایروال AD را برای همان نسخه و نقش بررسی و دسترسی را به مبدأهای لازم محدود کنید؛ این پورت‌ها نباید به‌صورت عمومی در اینترنت باز شوند.
- رمز حساب کامپیوتر با دامین هماهنگ نیست، مثلاً بعد از برگرداندن یک ماشین مجازی به Snapshot قدیمی. این حالت را secure channel خراب می گویند.
برای مشاهدهٔ DC انتخاب‌شده و وضعیت secure channel روی کامپیوتر عضو دامین، فرمان‌های تشخیصی زیر کاربرد دارند:
nltest /dsgetdc:ad.example.com
Test-ComputerSecureChannel -Verboseفرمان اول DC پیدا‌شده را نشان می‌دهد. Test-ComputerSecureChannel برای کامپیوتر عضو دامین است؛ روی DC ممکن است خطای کاذب بدهد. مقدار false به‌تنهایی مجوز تعمیر نیست؛ ابتدا DNS، زمان، دسترسی و وضعیت حساب دستگاه بررسی شود. تعمیر، تغییر state است و باید با دسترسی مجاز و روش مناسب همان نقش انجام شود.
اضافه کردن دامین کنترلر جدید و کنار گذاشتن قدیمی
سرور قدیمی ای که دامین کنترلر است را معمولاً نمی شود فقط خاموش کرد. ترتیب امن کار این است:
- ویندوز سرور جدید را به دامین بپیوندید و نقش AD DS را روی آن به صورت دامین کنترلر اضافه کنید.
- صبر کنید replication کامل شود و با
repadmin /replsummaryهیچ خطایی نبینید. - دارنده و دامنهٔ هر نقش FSMO را بررسی و فقط نقش‌های لازم را به DC مناسب منتقل کنید. انتقال همهٔ پنج نقش به یک مقصد نسخهٔ عمومی مهاجرت نیست؛ دو نقش در سطح فارست و سه نقش در سطح دامین‌اند.
- در DHCP و تنظیمات کامپیوترها آدرس DNS را به دامین کنترلر جدید تغییر دهید.
- دامین کنترلر قدیمی را با Server Manager یا دستور
Uninstall-ADDSDomainControllerبه صورت اصولی demote کنید و بعد خاموش کنید. حذف سرور بدون demote، رکوردهایش را در دایرکتوری باقی می گذارد و مدتی بعد خطای replication می دهد.
پیش از افزودن DC جدید، سازگاری نسخه، schema، functional level و وضعیت SYSVOL را بررسی کنید؛ محیط‌های قدیمی ممکن است به مهاجرت FRS به DFSR نیاز داشته باشند. افزایش functional level اقدام جداگانه با پیش‌نیاز و محدودیت بازگشت است و نباید صرفاً به دلیل تعویض یک سرور انجام شود.
شعبه ها و Sites
Site و نگاشت subnetها به AD کمک می‌کنند DC مناسب را پیدا کند؛ انتخاب واقعی به توپولوژی و دسترسی نیز وابسته است. در برخی شعبه‌ها RODC مناسب است، اما برخلاف تصور رایج ممکن است بر اساس Password Replication Policy اطلاعات اعتبارسنجی حساب‌های مجاز را cache کند. حساب‌های قابل cache و پیامد سرقت دستگاه باید در طراحی امنیت بررسی شوند.
اکتیو دایرکتوری و فضای ابری
AD DS روی دامین‌کنترلرهای تحت مدیریت سازمان اجرا می‌شود؛ این ماشین‌ها می‌توانند در محل شرکت یا زیرساخت میزبانی‌شده باشند. Microsoft Entra ID سرویس هویت ابری است و جایگزین مستقیم همهٔ قابلیت‌های AD DS نیست. همگام‌سازی هویت در طراحی ترکیبی با ابزار مناسب و تنظیمات امنیتی جداگانه انجام می‌شود؛ روش ورود و چرخهٔ عمر حساب‌ها باید مشخص باشند.
تفاوت اکتیو دایرکتوری و Microsoft Entra ID
| موضوع | اکتیو دایرکتوری (AD DS) | Microsoft Entra ID |
|---|---|---|
| محل اجرا | دامین‌کنترلر تحت مدیریت سازمان، در محل یا زیرساخت میزبانی‌شده | سرویس ابری مایکروسافت |
| پروتکل ورود | Kerberos و NTLM، با LDAP برای جستجو | OAuth 2.0، OpenID Connect و SAML |
| مدیریت تنظیمات کامپیوترها | Group Policy | ابزار جداگانه مانند Microsoft Intune، با مجوز و تنظیمات لازم |
| ساختار | دامین، فارست و OU | tenant و گروه ها، بدون OU |
| مناسب برای | سرورها و برنامه های داخلی | Microsoft 365 و برنامه های ابری |
انتخاب AD DS، Entra ID یا معماری ترکیبی به برنامه‌ها، دستگاه‌ها و روش مدیریت بستگی دارد. همگام‌سازی هویت به‌تنهایی همهٔ کاربردهای Kerberos، LDAP و Group Policy را به سرویس ابری منتقل نمی‌کند.
امنیت دامین کنترلر
دسترسی مدیریتی دامین می‌تواند دامنهٔ اثر نفوذ را افزایش دهد. تفکیک حساب‌ها، محدودکردن مجوز، به‌روزرسانی و بکاپ مستقل از اجزای کاهش ریسک‌اند و امنیت کامل را تضمین نمی‌کنند. برای بررسی بیشتر، باج‌افزار چیست و هاردنینگ سرور لینوکس و ویندوز را بخوانید.
مراحل نصب خود ویندوز سرور قبل از ساختن دامین در نصب ویندوز سرور 2022 آمده است.
حفاظت چندعاملی حساب‌های مدیریتی باید متناسب با روش ورود و ابزار مدیریت طراحی شود؛ فعال‌کردن MFA در یک سرویس ابری به‌تنهایی تمام ورودهای سنتی Kerberos یا NTLM را چندعاملی نمی‌کند.
منابع و مستندات رسمی
- مستندات رسمی Microsoft درباره Active Directory Domain Services
- مستندات رسمی Microsoft درباره Group Policy
- مستندات رسمی Microsoft درباره Microsoft Entra ID
- ورود با اطلاعات کش‌شدهٔ دامین — Microsoft
- محدودهٔ کاربرد Test-ComputerSecureChannel — Microsoft
- سلسله‌مراتب زمان Windows — Microsoft
- معماری حفاظتی دامین‌کنترلر مجازی — Microsoft
- سیاست رمز حساب‌های دامین — Microsoft
طراحی و راه اندازی دامین کنترلر، انتقال به دامین جدید و نگه داری روزمره آن از کارهای اکتیو دایرکتوری و ویندوز سرور است. اگر هنوز درباره سیستم عامل بقیه سرورها تصمیم نگرفته اید، مقایسه سرور لینوکس و ویندوز را هم بخوانید.
