مقدمه
اگه توی حوزه IT کار کنید، حتماً اسم اکتیو دایرکتوری (Active Directory) یا همون AD رو شنیدید. این سرویس، صادقانه بگم، یکی از حیاتیترین بخشهای زیرساخت شبکه در محیطهای سازمانی مبتنی بر ویندوز محسوب میشه. مایکروسافت این سرویس دایرکتوری رو توسعه داده و عملاً به عنوان مرکز مدیریت هویت و دسترسی (Identity and Access Management) عمل میکنه — یعنی مدیریت متمرکز کاربران، گروهها، رایانهها، سرورها و کلی منابع شبکهای دیگه.
حالا فکر کنید یه سازمان بزرگ با هزاران کاربر و صدها سرور. اکتیو دایرکتوری توی همچین محیطی نقش کلیدی ایفا میکنه:
- احراز هویت متمرکز (Centralized Authentication): کاربران با یک نام کاربری و رمز عبور واحد به تمام منابع مجاز دسترسی پیدا میکنن
- مدیریت سیاستهای امنیتی (Security Policy Management): اعمال یکپارچه سیاستهای امنیتی از طریق Group Policy در سراسر سازمان
- مدیریت دسترسیها (Access Control): کنترل دقیق دسترسی کاربران به منابع مختلف بر اساس نقش و مسئولیتشون
- یکپارچگی با سرویسهای مایکروسافت: ادغام کامل با Exchange Server، SharePoint، SQL Server و بقیه محصولات مایکروسافت
اما وقتی AD دچار مشکل بشه، ماجرا واقعاً میتونه فاجعهبار بشه.
از دست رفتن دسترسی به سرویسهای حیاتی، ناتوانی کاربران در ورود به سیستم، اختلال در فرآیندهای کسبوکار و حتی توقف کامل عملیات IT سازمان — اینا فقط بخشی از عواقب احتمالی هستن. باورتون نمیشه، یه مشکل ساده DNS میتونه باعث بشه صدها کاربر نتونن به سیستمشون وارد بشن، یا یه خطای Replication ممکنه منجر به ناسازگاری دادهها در کنترلرهای دامنه مختلف بشه.
به همین دلیل، تسلط بر عیبیابی اکتیو دایرکتوری یکی از مهارتهای اساسی برای هر متخصص IT و پشتیبان هلپ دسک به حساب میاد. خب، بیاید شروع کنیم و ببینیم با چه ابزارها و تکنیکهایی میتونیم رایجترین مشکلات AD رو شناسایی و رفع کنیم.
ابزارهای ضروری عیبیابی
قبل از اینکه بریم سراغ مشکلات خاص، باید با ابزارهای اصلی عیبیابی اکتیو دایرکتوری آشنا بشید. اینا ابزارهایی هستن که بهتون اجازه میدن سلامت دامنه رو بررسی کنید، مشکلات رو پیدا کرده و اقدامات اصلاحی انجام بدید.
ابزار dcdiag (Domain Controller Diagnostic)
dcdiag رو میشه گفت یکی از مهمترین ابزارهای خط فرمان برای تشخیص مشکلات کنترلر دامنهست. این ابزار مجموعهای از تستهای مختلف رو روی کنترلر دامنه اجرا میکنه و گزارش جامعی از وضعیت سلامت اون ارائه میده.
دستورات کلیدی dcdiag:
dcdiag /v
این دستور تمام تستهای استاندارد رو با خروجی مفصل (verbose) اجرا میکنه. تستهایی مثل Connectivity، Replications، Topology، NCSecDesc، NetLogons و خیلی موارد دیگه.
dcdiag /test:dns /v
فقط تست DNS رو اجرا میکنه و مشکلات مربوط به پیکربندی DNS رو شناسایی میکنه.
dcdiag /a
تستها رو روی تمام کنترلرهای دامنه اجرا میکنه — خیلی مفیده وقتی میخواید سلامت کل زیرساخت AD رو یکجا بررسی کنید.
ابزار repadmin (Replication Diagnostics Tool)
repadmin ابزار قدرتمندی برای نظارت و عیبیابی Replication در اکتیو دایرکتوریه. با این ابزار میتونید وضعیت همگامسازی بین کنترلرهای دامنه رو زیر نظر بگیرید.
دستورات مهم repadmin:
repadmin /replsummary
خلاصهای از وضعیت Replication در کل محیط AD رو نشون میده، شامل تعداد خطاها و آخرین زمان همگامسازی موفق.
repadmin /showrepl
جزئیات کامل Replication برای کنترلر دامنه، شامل Replication Partners، وضعیت آخرین همگامسازی و خطاهای احتمالی.
repadmin /syncall /AdeP
اجبار به همگامسازی فوری تمام Partitionهای دایرکتوری با تمام Replication Partners. پارامتر A برای All Partitions، d برای Distinguished Names، e برای Enterprise و P برای Push از سرور محلی استفاده میشه.
ابزار nltest (Network Logon Test)
nltest برای آزمایش اتصالات Secure Channel بین ایستگاههای کاری و کنترلرهای دامنه کاربرد داره.
nltest /sc_query:domain.com
وضعیت Secure Channel با دامنه مشخص شده رو بررسی میکنه.
nltest /sc_reset:domain.com
Secure Channel رو بازنشانی میکنه — این دستور خیلی وقتا مشکل معروف "The trust relationship between this workstation and the primary domain failed" رو حل میکنه.
nltest /dsgetdc:domain.com
کنترلر دامنه مناسب رو پیدا کرده و اطلاعاتش رو نمایش میده.
Event Viewer (نمایشگر رویدادها)
Event Viewer یکی از مهمترین منابع اطلاعاتی برای عیبیابیه. من شخصاً خیلی وقتا اولین جایی که بررسی میکنم همینه. در بخش Windows Logs و Applications and Services Logs، اطلاعات حیاتی درباره مشکلات AD ثبت میشه.
مهمترین Logهای مربوط به اکتیو دایرکتوری:
- Directory Service Log: واقع در Applications and Services Logs → Microsoft → Windows → ActiveDirectory_DomainService
- DNS Server Log: در Applications and Services Logs → DNS Server
- System Log: برای خطاهای Netlogon و NTDS
- Security Log: برای رویدادهای احراز هویت و Account Lockout
PowerShell Cmdlets
پاورشل واقعاً یه ابزار فوقالعاده قدرتمند برای مدیریت و عیبیابی اکتیو دایرکتوریه. ماژول ActiveDirectory شامل دهها cmdlet کاربردیه.
نمونههای کاربردی:
Import-Module ActiveDirectory
Get-ADDomainController -Filter * | Select-Object Name, IPv4Address, OperatingSystem
Get-ADReplicationFailure -Target "DC01.domain.com"
Get-ADUser -Identity "username" -Properties LockedOut, AccountLockoutTime, LastBadPasswordAttempt
Test-ComputerSecureChannel -Verbose
Get-ADReplicationPartnerMetadata -Target "DC01.domain.com" -Scope Server
این cmdletها امکان اتوماسیون بسیاری از وظایف عیبیابی رو فراهم میکنن و میشه توی اسکریپتهای مانیتورینگ هم ازشون استفاده کرد.
مشکلات رایج احراز هویت و قفل شدن حسابها
خب، بریم سراغ یکی از دردسرسازترین مشکلات دنیای هلپ دسک: قفل شدن حسابهای کاربری (Account Lockout). اگه توی هلپ دسک کار کرده باشید، حتماً میدونید که تیکتهای "حساب من قفل شده" چقدر رایجه! پیدا کردن علت اصلیش هم گاهی واقعاً چالشبرانگیزه.
علل رایج قفل شدن حسابها
- اعتبارنامههای ذخیره شده قدیمی: رمزهای عبور قدیمی ذخیره شده در Credential Manager، Mapped Network Drives یا برنامههای موبایل
- سرویسهای ویندوز: سرویسهایی که با اعتبارنامههای منقضی شده یا اشتباه اجرا میشن
- Task Scheduler: وظایف زمانبندی شده با رمز عبور قدیمی
- دستگاههای موبایل: گوشیها و تبلتهایی که به Exchange متصلن با رمز عبور قدیمی (این مورد خیلی رایجه!)
- اتصالات RDP و Terminal Services ذخیره شده: نشستهای Remote Desktop با اعتبارنامههای قدیمی
- حملات Brute Force: تلاشهای مخرب برای حدس زدن رمز عبور
- مشکلات همگامسازی زمان: اختلاف زمانی بین کلاینت و کنترلر دامنه
شناسایی منبع قفل شدن حساب با Event ID
برای ردیابی دقیق علت قفل شدن حساب، باید Event IDهای خاصی رو در کنترلرهای دامنه بررسی کنید:
| Event ID | منبع | توضیحات |
|---|---|---|
| 4740 | Security Log | حساب کاربری قفل شد — شامل نام کامپیوتری که باعث قفل شدن شده |
| 4625 | Security Log | تلاش ناموفق برای ورود — شامل جزئیات Failure Reason و Workstation Name |
| 4776 | Security Log | کنترلر دامنه تلاش کرد اعتبارنامهها رو تأیید کنه (NTLM) |
| 4771 | Security Log | Kerberos pre-authentication ناموفق بود |
| 4768 | Security Log | Kerberos TGT درخواست شد (موفق) |
| 4769 | Security Log | Kerberos Service Ticket درخواست شد |
مراحل عیبیابی قفل شدن حساب
گام اول: بررسی وضعیت حساب کاربری
Get-ADUser -Identity "username" -Properties LockedOut, AccountLockoutTime, BadLogonCount, LastBadPasswordAttempt | Format-List Name, LockedOut, AccountLockoutTime, BadLogonCount, LastBadPasswordAttempt
گام دوم: باز کردن قفل حساب
Unlock-ADAccount -Identity "username"
گام سوم: پیدا کردن کنترلر دامنهای که حساب در آن قفل شده
برای این کار باید Event ID 4740 رو در تمام کنترلرهای دامنه جستجو کنید. با PowerShell میتونید این کار رو خودکار انجام بدید:
$DCs = Get-ADDomainController -Filter *
foreach ($DC in $DCs) {
Get-WinEvent -ComputerName $DC.HostName -FilterHashtable @{
LogName='Security'
ID=4740
StartTime=(Get-Date).AddHours(-24)
} -ErrorAction SilentlyContinue |
Where-Object {$_.Properties[0].Value -eq "username"} |
Select-Object TimeCreated, MachineName, Message
}
گام چهارم: شناسایی منبع اصلی با بررسی Caller Computer Name
در Event ID 4740، فیلد "Caller Computer Name" نشون میده کدوم کامپیوتر باعث قفل شدن حساب شده. بعد باید اون دستگاه رو بررسی کنید:
- Credential Manager رو توی ویندوز چک کنید
- Mapped Network Drives و اعتبارنامههای ذخیره شدهشون رو بررسی کنید
- سرویسهای در حال اجرا با حساب کاربری مشکلدار رو شناسایی کنید
- Task Scheduler رو برای وظایف با اعتبارنامههای قدیمی بررسی کنید
- برنامههای موبایل متصل به Exchange یا سایر سرویسها رو چک کنید
ابزار Account Lockout and Management Tools
مایکروسافت یه ابزار رایگان به اسم "Account Lockout and Management Tools" ارائه داده که شامل LockoutStatus.exe هست. با این ابزار میتونید وضعیت قفل شدن یه حساب رو توی تمام کنترلرهای دامنه به صورت همزمان ببینید. اطلاعاتی مثل وضعیت قفل بودن، تعداد تلاشهای ناموفق ورود، زمان آخرین تلاش ناموفق و کنترلر دامنه مربوطه رو نمایش میده.
پیشگیری از قفل شدن مکرر حسابها
برای کاهش موارد قفل شدن حساب، این اقدامات رو انجام بدید:
- سیاست Account Lockout رو بررسی و در صورت لزوم تنظیم کنید (Account Lockout Duration، Account Lockout Threshold، Reset Account Lockout Counter)
- از Fine-Grained Password Policies برای گروههای مختلف کاربران استفاده کنید
- کاربران رو درباره مدیریت صحیح رمز عبور و اعتبارنامههای ذخیره شده آموزش بدید
- سیستم مانیتورینگ برای شناسایی الگوهای مشکوک قفل شدن حسابها پیادهسازی کنید
- از Multi-Factor Authentication برای افزایش امنیت استفاده کنید
عیبیابی مشکلات Replication
Replication یکی از مهمترین فرآیندهای AD هست که تضمین میکنه تمام تغییرات در یک کنترلر دامنه به سایر کنترلرها منتقل بشه. وقتی Replication مشکل پیدا کنه، ممکنه با ناسازگاری دادهها، مشکلات احراز هویت و حتی از دست رفتن دادهها مواجه بشید.
راستش، از تجربه شخصی بگم: مشکلات Replication اگه سریع شناسایی نشن، میتونن خیلی سریع گسترش پیدا کنن و یه بحران تمامعیار ایجاد کنن.
علائم مشکلات Replication
- تغییرات در یک DC در DCهای دیگه دیده نمیشه
- کاربران نمیتونن به بعضی سرورها وارد بشن اما به بقیه میتونن
- تغییرات Group Policy اعمال نمیشه
- خطاهای Replication در Event Viewer
- دستور dcdiag یا repadmin خطاهای Replication رو نشون میده
Event ID 2042: Tombstone Lifetime Issue
Event ID 2042 یکی از جدیترین هشدارهای مربوط به Replication هست. این رویداد وقتی رخ میده که یه کنترلر دامنه برای مدت طولانی (بیشتر از Tombstone Lifetime) از شبکه قطع بوده و دیگه نمیتونه به صورت ایمن Replication انجام بده.
Tombstone Lifetime چیه؟
Tombstone Lifetime مدت زمانیه که یه شیء حذف شده (به صورت منطقی) توی دایرکتوری نگهداری میشه قبل از اینکه کاملاً پاک بشه. مقدار پیشفرضش توی ویندوز Server 2003 SP2 و بالاتر ۱۸۰ روزه.
برای بررسی Tombstone Lifetime فعلی:
Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=domain,DC=com" -Properties tombstoneLifetime | Select-Object tombstoneLifetime
راهحل Event ID 2042:
در بیشتر موارد، بهترین کار اینه که کنترلر دامنه مشکلدار رو کاملاً از دامنه حذف کنید (Demote) و بعد دوباره به عنوان کنترلر دامنه ارتقاش بدید (Promote). ولی قبل از انجام این کار:
- مطمئن بشید که حداقل دو کنترلر دامنه سالم دیگه توی محیط دارید
- بررسی کنید آیا DC مشکلدار نقشهای FSMO داره یا نه
- در صورت داشتن نقشهای FSMO، اونها رو به DC دیگهای منتقل کنید
- Metadata Cleanup انجام بدید
بررسی وضعیت Replication با repadmin
repadmin /replsummary
خروجی این دستور نشون میده کدوم DCها خطای Replication دارن و آخرین همگامسازی موفق کی بوده.
repadmin /showrepl
اطلاعات تفصیلی درباره تمام Partitionهای دایرکتوری و وضعیت Replication اونها رو نمایش میده.
repadmin /queue
تغییراتی که توی صف انتظار برای Replication هستن رو نشون میده.
علل رایج مشکلات Replication و راهحلها
۱. مشکلات DNS:
DNS نقش کلیدی در Replication داره (بازم DNS!). اگه SRV Recordهای کنترلرهای دامنه به درستی توی DNS ثبت نشده باشن، Replication با مشکل مواجه میشه.
dcdiag /test:dns /v
ipconfig /registerdns
۲. مشکلات Network Connectivity:
بررسی کنید که آیا کنترلرهای دامنه میتونن با همدیگه ارتباط برقرار کنن:
Test-NetConnection -ComputerName DC01.domain.com -Port 389
Test-NetConnection -ComputerName DC01.domain.com -Port 135
Test-NetConnection -ComputerName DC01.domain.com -Port 445
پورتهای مورد نیاز برای Replication: 389 (LDAP)، 636 (LDAPS)، 3268 (Global Catalog)، 3269 (Global Catalog SSL)، 88 (Kerberos)، 53 (DNS)، 135 (RPC)، 445 (SMB) و محدوده Dynamic RPC یعنی 49152-65535 در ویندوزهای جدید.
۳. اختلاف زمانی (Time Skew):
Kerberos به همگامسازی دقیق زمان بین سرورها نیاز داره. حداکثر اختلاف مجاز فقط ۵ دقیقهست:
w32tm /query /status
w32tm /resync /rediscover
Lingering Objects
Lingering Objects اشیائی هستن که توی یه کنترلر دامنه حذف شدن ولی توی کنترلر دیگهای که مدت طولانی Offline بوده، هنوز وجود دارن. این قضیه میتونه باعث خطاهای Replication بشه.
repadmin /removelingeringobjects DC01.domain.com dc=domain,dc=com /advisory_mode
توی حالت Advisory Mode، فقط Lingering Objects شناسایی و گزارش میشن بدون اینکه حذف بشن. این خیلی مهمه — همیشه اول با advisory_mode بررسی کنید.
جدول Event IDهای مهم Replication
| Event ID | منبع | توضیحات | اقدام |
|---|---|---|---|
| 1311 | NTDS KCC | Knowledge Consistency Checker نتونست Topology ایجاد کنه | بررسی DNS و اتصال شبکه |
| 1865 | NTDS Replication | خطای Replication به دلیل مشکلات DNS | بررسی SRV Records و پیکربندی DNS |
| 1925 | NTDS KCC | تلاش برای ایجاد Replication Link ناموفق بود | بررسی اتصال شبکه و Firewall |
| 2042 | NTDS Replication | Tombstone Lifetime تجاوز شده | Demote و Promote مجدد DC یا Metadata Cleanup |
| 2087 | NTDS Replication | Replication با خطای "Access Denied" مواجه شد | بررسی مجوزهای Replication و اعتبارنامهها |
| 2088 | NTDS Replication | Replication برای مدت طولانی انجام نشده | بررسی علت عدم Replication و اجبار به همگامسازی |
مشکلات DNS مرتبط با اکتیو دایرکتوری
DNS رو میشه قلب تپنده اکتیو دایرکتوری دونست. بدون DNS سالم، هیچ سرویس AD به درستی کار نمیکنه. کنترلرهای دامنه از DNS برای پیدا کردن همدیگه، کلاینتها از DNS برای پیدا کردن کنترلرهای دامنه و تمام سرویسهای AD-integrated از DNS برای عملکرد صحیح استفاده میکنن.
صادقانه بگم، از هر ۱۰ مشکل AD که باهاش مواجه شدم، حداقل ۷ تاش ریشهاش به DNS برمیگرده.
SRV Records (Service Location Records)
SRV Recordها رکوردهای DNS خاصی هستن که مشخص میکنن کدوم سرور، کدوم سرویس رو ارائه میده. برای اکتیو دایرکتوری، این SRV Recordهای حیاتی باید وجود داشته باشن:
- _ldap._tcp.dc._msdcs.domain.com — برای خدمات LDAP کنترلرهای دامنه
- _kerberos._tcp.dc._msdcs.domain.com — برای خدمات Kerberos
- _ldap._tcp.gc._msdcs.domain.com — برای Global Catalog سرورها
- _kerberos._udp.domain.com — برای احراز هویت Kerberos
- _kpasswd._tcp.domain.com — برای تغییر رمز عبور Kerberos
بررسی SRV Records با nslookup
nslookup
set type=srv
_ldap._tcp.dc._msdcs.domain.com
یا با پاورشل:
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.domain.com -Type SRV
خروجی باید تمام کنترلرهای دامنه رو نشون بده. اگه کنترلر دامنهای توی لیست نیست، مشکل ثبت DNS داره.
ثبت مجدد SRV Records
اگه SRV Recordهای یه کنترلر دامنه توی DNS ثبت نشدن، میتونید با دستورات زیر دوباره ثبتشون کنید:
net stop netlogon
net start netlogon
سرویس Netlogon مسئول ثبت SRV Recordها توی DNS هست. ریستارت این سرویس باعث میشه تمام رکوردها دوباره ثبت بشن.
ipconfig /registerdns
عیبیابی DNS با dcdiag
dcdiag /test:dns /v
این دستور تستهای زیر رو انجام میده:
- Authentication (Auth): آیا DC میتونه DNS Server رو احراز هویت کنه
- Basic (Basc): آیا رکورد A برای DC توی DNS وجود داره
- Forwarders/Root hints (Forw): آیا Forwarder یا Root Hints درست پیکربندی شدن
- Delegations (Del): آیا Delegationهای DNS درست پیکربندی شدن
- Dynamic update (Dyn): آیا Dynamic Update توی DNS فعاله
- Records registration (RReg): آیا تمام رکوردهای ضروری ثبت شدن
برای تست DNS روی تمام کنترلرهای دامنه:
dcdiag /test:dns /a /v
Event ID 4013: DNS Server نتونست دادههای AD رو بارگذاری کنه
این خطا وقتی رخ میده که DNS Server نتونه Zoneهای AD-Integrated رو از اکتیو دایرکتوری بارگذاری کنه. معمولاً توی این موارد اتفاق میافته:
- کنترلر دامنه تازه ارتقا یافته و هنوز Replication کامل نشده
- مشکلات Replication بین کنترلرهای دامنه
- خرابی پایگاه داده اکتیو دایرکتوری
- مشکل در دسترسی به Partition مربوط به DNS
راهحلهای Event ID 4013:
repadmin /showrepl
repadmin /replsummary
repadmin /syncall /AdeP
بهترین شیوههای DNS برای اکتیو دایرکتوری
- همیشه از AD-Integrated Zoneها استفاده کنید (نه Secondary یا Primary سنتی)
- حداقل دو DNS Server در هر سایت داشته باشید
- کنترلرهای دامنه باید به خودشون و سایر DCها به عنوان Primary و Secondary DNS اشاره کنن
- هرگز یه کنترلر دامنه رو فقط به DNS خارجی (مثل 8.8.8.8) اشاره ندید — این اشتباه خیلی رایجه!
- از Secure Dynamic Update استفاده کنید تا فقط کامپیوترهای Authenticated بتونن رکورد ثبت کنن
- Scavenging رو با دقت پیکربندی و مانیتور کنید
عیبیابی Group Policy (GPO Troubleshooting)
Group Policy یکی از قدرتمندترین ابزارهای مدیریت متمرکز توی اکتیو دایرکتوریه. اما وقتی GPO درست اعمال نشه، میتونه باعث مشکلات گستردهای بشه.
ابزار gpresult برای بررسی GPOهای اعمال شده
gpresult /r
خلاصهای از GPOهای اعمال شده رو نشون میده.
gpresult /h C:\GPReport.html
یه گزارش کامل HTML ایجاد میکنه که شامل تمام جزئیات GPOهای اعمال شده و تنظیماتشونه. این گزارش HTML واقعاً خوانایی عالیای داره.
ابزار gpupdate برای اعمال فوری GPO
gpupdate /force
تمام GPOها رو (چه تغییر کرده باشن چه نه) دوباره اعمال میکنه.
gpupdate /target:computer /force
gpupdate /target:user /force
اعمال فوری فقط Computer Configuration یا User Configuration.
Event IDهای مهم Group Policy
| Event ID | منبع | توضیحات | اقدام |
|---|---|---|---|
| 1030 | Group Policy | پردازش GPO ناموفق بود — خطای عمومی | بررسی Event Log برای جزئیات بیشتر |
| 1053 | Group Policy | دسترسی به لیست GPO از AD ناموفق بود | بررسی اتصال شبکه، DNS و دسترسی به SYSVOL |
| 1054 | Group Policy | دسترسی به فایلهای GPO از SYSVOL ناموفق بود | بررسی دسترسی به SYSVOL، مجوزها و FRS/DFSR Replication |
| 1085 | Group Policy | دسترسی به SYSVOL از طریق SMB ناموفق بود | بررسی Firewall، SMB Service و مجوزها |
علل رایج مشکلات Group Policy
۱. مشکلات دسترسی به SYSVOL:
GPOها در دو مکان ذخیره میشن: تنظیمات اصلی توی AD و فایلهای Template توی SYSVOL. اگه دسترسی به SYSVOL وجود نداشته باشه، GPO اعمال نمیشه.
Test-Path \\domain.com\SYSVOL
۲. مشکلات Replication SYSVOL (FRS یا DFSR):
SYSVOL بین کنترلرهای دامنه Replicate میشه. اگه Replication کار نکنه، کلاینتهای متصل به DCهای مختلف ممکنه GPOهای متفاوت دریافت کنن — که خب یه وضعیت خیلی گیجکنندهای ایجاد میکنه.
dfsrmig /getglobalstate
Get-DfsrBacklog -GroupName "Domain System Volume" -FolderName "SYSVOL Share"
۳. مشکلات Filtering:
اگه یه کاربر یا کامپیوتر عضو گروههای مجاز توی Security Filtering نباشه یا شرایط WMI Filter رو برآورده نکنه، GPO اعمال نمیشه.
Get-GPPermission -Name "GPOName" -All
Get-GPInheritance -Target "OU=Sales,DC=domain,DC=com"
عیبیابی گام به گام GPO
گام ۱: بررسی اتصال به دامنه و کنترلر دامنه
nltest /sc_query:domain.com
echo %LOGONSERVER%
گام ۲: بررسی دسترسی به SYSVOL
dir \\%LOGONSERVER%\SYSVOL
گام ۳: اعمال فوری GPO و بررسی Event Log
gpupdate /force
توی Event Viewer برید به Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational.
گام ۴: بررسی GPOهای اعمال شده با gpresult
gpresult /h C:\GPReport.html
برای فعال کردن Logging پیشرفته GPO:
reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" /v GPSvcDebugLevel /t REG_DWORD /d 0x00030002 /f
مشکلات Trust و ارتباط بین دامنهها
Trust Relationship امکان میده کاربران در یه دامنه به منابع دامنه دیگهای دسترسی داشته باشن. مشکلات Trust میتونه باعث بشه کاربران نتونن به سیستمهاشون وارد بشن یا به منابع مشترک دسترسی پیدا کنن.
پیام خطای معروف Trust Relationship
اگه توی IT کار میکنید، احتمالاً این پیام رو خوب میشناسید:
"The trust relationship between this workstation and the primary domain failed"
این خطا معمولاً یعنی Secure Channel بین کامپیوتر و کنترلر دامنه شکسته شده. دلایل رایجش اینان:
- رمز عبور حساب کامپیوتر (Computer Account Password) تغییر کرده ولی Synchronize نشده
- کامپیوتر برای مدت طولانی از دامنه قطع بوده (بیش از ۳۰ روز)
- حساب کامپیوتر از AD حذف و دوباره ایجاد شده
- Restore از Backup قدیمی انجام شده
- Clone شدن Virtual Machine بدون Sysprep
راهحلهای Trust Relationship Failure
روش ۱: بازنشانی Secure Channel با PowerShell (سریعترین روش)
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
این دستور Secure Channel رو آزمایش کرده و در صورت نیاز بازنشانی میکنه.
روش ۲: استفاده از nltest
nltest /sc_reset:domain.com
روش ۳: Unjoin و Rejoin به دامنه
اگه روشهای بالا کار نکردن، باید کامپیوتر رو از دامنه خارج کرده و دوباره Join کنید:
- به صورت Local Administrator وارد بشید
- System Properties → Computer Name → Change رو باز کنید
- کامپیوتر رو به Workgroup منتقل کنید و Restart کنید
- دوباره به دامنه Join کنید و Restart کنید
روش ۴: استفاده از netdom
netdom reset COMPUTERNAME /domain:domain.com /usero:domain\adminuser /passwordo:*
عیبیابی Trust بین دامنهها
nltest /sc_query:TRUSTEDDOMAIN.com
nltest /domain_trusts
Get-ADTrust -Filter *
netdom trust TRUSTINGDOMAIN.com /domain:TRUSTEDDOMAIN.com /verify
مشکلات مربوط به آپدیت سپتامبر ۲۰۲۵ مایکروسافت
در سپتامبر ۲۰۲۵، مایکروسافت یه بهروزرسانی امنیتی مهم منتشر کرد که برای بعضی سازمانها مشکلات قابل توجهی ایجاد کرد. دو مشکل عمده شناسایی شده که اگه سازمانتون رو آپدیت کردید (یا قراره بکنید)، حتماً باید ازشون خبر داشته باشید.
مشکل گروههای امنیتی بزرگ (بیش از ۱۰,۰۰۰ عضو)
یکی از تغییرات کلیدی توی این آپدیت، تأثیرش روی گروههای امنیتی با بیش از ۱۰,۰۰۰ عضو بود. این مشکل میتونه منجر به Replication Failures، Token Bloat، کاهش عملکرد احراز هویت و خطاهای Kerberos بشه.
شناسایی گروههای بزرگ:
Get-ADGroup -Filter * -Properties Members |
Where-Object {$_.Members.Count -gt 5000} |
Select-Object Name, @{Name="MemberCount";Expression={$_.Members.Count}} |
Sort-Object MemberCount -Descending
راهحلها:
- تقسیم گروههای بزرگ: گروههای بزرگ رو به گروههای کوچکتر تقسیم کنید و از Nested Groups استفاده کنید
- بررسی عضویتهای غیرضروری: اعضای غیرفعال یا غیرضروری رو حذف کنید
- استفاده از Dynamic Groups: در صورت امکان از Query-based Groups استفاده کنید
مشکلات Entra Connect Sync (Azure AD Connect)
آپدیت سپتامبر ۲۰۲۵ همچنین باعث مشکلاتی توی Entra Connect Sync شد. سازمانهایی که از Hybrid Identity استفاده میکنن ممکنه با Synchronization Failures، مشکل Password Hash Sync و تأخیر در Provisioning مواجه بشن.
بررسی وضعیت:
Import-Module ADSync
Get-ADSyncScheduler
Get-ADSyncConnectorRunStatus
اجرای Full Sync:
Start-ADSyncSyncCycle -PolicyType Initial
مانیتورینگ پس از آپدیت
بعد از نصب آپدیتهای مهم، حتماً این موارد رو بررسی کنید:
- وضعیت Replication با
repadmin /replsummary - خطاهای Event Viewer در تمام کنترلرهای دامنه
- عملکرد احراز هویت کاربران
- وضعیت Group Policy Processing
- عملکرد Entra Connect Sync
بهترین شیوههای پیشگیری و نظارت
خب، حالا که مشکلات رو شناختیم، بیاید از پیشگیری حرف بزنیم. همه میدونیم پیشگیری بهتر از درمانه! با اجرای استراتژیهای مانیتورینگ و نگهداری منظم، میتونید خیلی از مشکلات AD رو قبل از اینکه بحرانی بشن شناسایی و رفع کنید.
مانیتورینگ مداوم سلامت اکتیو دایرکتوری
۱. اجرای روزانه dcdiag:
یه اسکریپت زمانبندی شده بسازید که هر روز dcdiag رو روی تمام DCها اجرا کنه و گزارش رو ایمیل کنه:
$DCs = Get-ADDomainController -Filter *
$report = @()
foreach ($DC in $DCs) {
$result = dcdiag /s:$DC.HostName /v
$report += "===================="
$report += "DC: $($DC.HostName)"
$report += "===================="
$report += $result
}
$report | Out-File C:\ADHealthReport.txt
Send-MailMessage -From "[email protected]" -To "[email protected]" -Subject "Daily AD Health Report" -Body ($report -join "`n") -SmtpServer "smtp.domain.com"
۲. مانیتورینگ Replication:
$replSummary = repadmin /replsummary
if ($replSummary -match "error" -or $replSummary -match "fail") {
Send-MailMessage -From "[email protected]" -To "[email protected]" -Subject "AD Replication Alert" -Body "Replication errors detected" -SmtpServer "smtp.domain.com"
}
۳. نظارت بر Event Logهای حیاتی:
Get-WinEvent -FilterHashtable @{
LogName='Directory Service'
Level=2,3
StartTime=(Get-Date).AddHours(-24)
} |
Where-Object {$_.Id -in @(2042,1311,1865,1925)} |
Select-Object TimeCreated, Id, Message
بررسیهای دورهای سلامت (Health Checks)
بررسی هفتگی:
- وضعیت Backup تمام کنترلرهای دامنه
- فضای دیسک کنترلرهای دامنه
- Performance Counters (CPU، Memory، Disk I/O)
- وضعیت سرویسهای حیاتی (NTDS، DNS، Netlogon، KDC)
- بررسی حسابهای قفل شده و الگوهای مشکوک
Get-Service -ComputerName DC01 -Name NTDS,DNS,Netlogon,KDC | Select-Object Name, Status
بررسی ماهانه:
- بررسی و تمیز کردن حسابهای کاربری غیرفعال
- بررسی حسابهای کامپیوتری Stale
- Audit تغییرات Schema
- بررسی GPOهای استفاده نشده
- Audit تغییرات در گروههای Privileged مثل Domain Admins و Enterprise Admins
$staleDate = (Get-Date).AddDays(-90)
Get-ADComputer -Filter {LastLogonDate -lt $staleDate -and Enabled -eq $true} -Properties LastLogonDate |
Select-Object Name, LastLogonDate
استراتژی Backup و Disaster Recovery
۱. System State Backup روزانه:
wbadmin start systemstatebackup -backupTarget:E: -quiet
۲. Bare Metal Backup هفتگی: حداقل برای یه کنترلر دامنه توی هر سایت، Full Server Backup داشته باشید.
۳. تست منظم Restore: حداقل سالانه یه بار فرآیند Restore رو تمرین کنید. جدی میگم — بکاپی که تست نشده، بکاپ نیست!
۴. مستندسازی Disaster Recovery Plan: یه سند جامع DR داشته باشید که شامل نقشهای FSMO، Topology، تنظیمات DNS، فرآیند Restore و اطلاعات تماس تیم باشه.
امنیت و Hardening اکتیو دایرکتوری
- Implement Least Privilege: کاربران فقط دسترسیهای ضروری داشته باشن
- Protect Privileged Accounts: از PAW (Privileged Access Workstation) برای حسابهای Admin استفاده کنید
- Enable Advanced Audit Policies: Audit دقیق برای تغییرات حیاتی فعال کنید
- Implement LAPS: از Local Administrator Password Solution برای مدیریت رمز Local Admin استفاده کنید
- Regular Patching: بهروزرسانی منظم تمام کنترلرهای دامنه
- Network Segmentation: جداسازی کنترلرهای دامنه توی VLAN امن
- Disable Legacy Protocols: غیرفعال کردن پروتکلهای قدیمی مثل SMBv1 و NTLMv1
اسکریپت جامع مانیتورینگ روزانه
$reportPath = "C:\ADHealthReports"
$date = Get-Date -Format "yyyy-MM-dd"
$reportFile = "$reportPath\ADHealth_$date.html"
$html = @"
<html>
<head><title>AD Health Report - $date</title></head>
<body>
<h1>Active Directory Health Report</h1>
<h2>Generated: $(Get-Date)</h2>
"@
# DC Status
$html += "<h2>Domain Controllers Status</h2>"
$DCs = Get-ADDomainController -Filter *
$dcStatus = $DCs | ForEach-Object {
[PSCustomObject]@{
Name = $_.Name
Site = $_.Site
IPv4 = $_.IPv4Address
Reachable = Test-Connection -ComputerName $_.HostName -Count 1 -Quiet
}
}
$html += $dcStatus | ConvertTo-Html -Fragment
# Replication Status
$html += "<h2>Replication Status</h2>"
$replSummary = repadmin /replsummary
$html += "<pre>$replSummary</pre>"
$html += "</body></html>"
$html | Out-File $reportFile
نتیجهگیری
اکتیو دایرکتوری ستون فقرات زیرساخت IT در بسیاری از سازمانهاست و عیبیابی صحیح و بهموقعش، مهارتی حیاتی برای هر متخصص IT و پشتیبان هلپ دسکه. توی این راهنما، طیف گستردهای از مشکلات رایج و پیشرفته AD رو بررسی کردیم و راهحلهای عملی برای هرکدوم ارائه دادیم.
نکات کلیدی که باید یادتون بمونه:
- ابزارها رو بشناسید: تسلط بر dcdiag، repadmin، nltest، gpresult و PowerShell cmdletهای مربوط به AD، پایه و اساس عیبیابی موفقه
- رویکرد سیستماتیک داشته باشید: از یه روش گام به گام برای شناسایی و حل مشکلات استفاده کنید، نه حدس و گمان
- Event Viewer رو دوست خودتون بدونید: خیلی از جوابها توی Event Logها پنهانن — یاد بگیرید کجا و چی رو جستجو کنید
- DNS رو فراموش نکنید: اکثر مشکلات AD به نوعی به DNS مربوط میشن — همیشه DNS رو بررسی کنید
- Replication رو مانیتور کنید: مشکلات Replication میتونه سریع گسترش پیدا کنه — زودتر شناساییشون کنید
- پیشگیری بهتر از درمانه: سرمایهگذاری توی مانیتورینگ پیشگیرانه و نگهداری منظم، جلوی خیلی از بحرانها رو میگیره
- مستندسازی کنید: تمام تغییرات، تنظیمات و راهحلهای موفق رو مستند کنید
- Backup بگیرید: همیشه قبل از هر تغییر مهم Backup داشته باشید و مرتب Restore رو تست کنید
عیبیابی موفق ترکیبی از دانش فنی، تجربه عملی، صبر و روشهای سیستماتیکه. با ابزارها و تکنیکهایی که توی این راهنما معرفی شدن، میتونید اکثر مشکلات AD رو سریع شناسایی و حل کنید.
در نهایت، هدف فقط حل مشکلات نیست، بلکه ساختن یه محیط پایدار، امن و قابل اعتماده — محیطی که کاربران بتونن بدون وقفه کارشون رو انجام بدن. با مانیتورینگ مداوم و آمادگی برای رویارویی با چالشها، میتونید مطمئن بشید زیرساخت AD سازمانتون همیشه در بهترین وضعیت قرار داره.