عیب‌یابی اکتیو دایرکتوری: راهنمای کامل رفع مشکلات AD برای هلپ دسک

راهنمای عملی عیب‌یابی اکتیو دایرکتوری برای متخصصین IT و هلپ دسک. رفع مشکلات احراز هویت، قفل شدن حساب، Replication، DNS، Group Policy و Trust با دستورات و اسکریپت‌های کاربردی.

مقدمه

اگه توی حوزه 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 سازمان‌تون همیشه در بهترین وضعیت قرار داره.

درباره نویسنده Editorial Team

Our team of expert writers and editors.