Account Lockout در ADAudit Plus؛ پیدا کردن منبع قفل شدن حساب در Active Directory

یک کاربر تماس می‌گیرد و می‌گوید حساب Active Directory او دوباره قفل شده است. Help Desk حساب را Unlock می‌کند، کاربر وارد می‌شود و چند دقیقه بعد همان اتفاق تکرار می‌شود. اگر فقط حساب را باز کنیم، در واقع نشانه را برطرف کرده‌ایم؛ نه علت را.

در بسیاری از محیط‌های Windows، عامل اصلی قفل شدن تکراری حساب یک Credential قدیمی است که جایی در پس‌زمینه مانده: یک Windows Service، Scheduled Task، Mapped Drive، Session قدیمی، نرم‌افزار سازمانی یا دستگاهی که هنوز با Password قبلی Authentication می‌کند. در سناریوهای دیگر هم ممکن است Lockout نتیجه Password Spray، Brute Force یا رفتار غیرعادی روی یک حساب حساس باشد.

ManageEngine ADAudit Plus برای همین نقطه ارزش پیدا می‌کند: به‌جای اینکه کارشناس بین Event Log چند Domain Controller و سیستم مبدا جابه‌جا شود، گزارش Account Lockout Analyzer اطلاعات «چه کسی، چه زمانی، از کجا و با چه الگوی قبلی» را کنار هم قرار می‌دهد. اگر هدف شما ارزیابی محصول و خدمات لایسنس، استقرار یا پشتیبانی است، صفحه ADAudit Plus مدانت نقطه شروع مناسبی است.

Account Lockout دقیقاً چه زمانی رخ می‌دهد؟

Active Directory می‌تواند بعد از تعداد مشخصی تلاش ناموفق برای ورود، حساب کاربر را قفل کند. این رفتار از طریق Account Lockout Policy کنترل می‌شود و سه مؤلفه اصلی دارد:

• Account lockout threshold: تعداد تلاش ناموفق قبل از Lock شدن حساب.
• Account lockout duration: مدت زمانی که حساب قفل باقی می‌ماند.
• Reset account lockout counter after: مدت زمانی که بعد از آن شمارنده تلاش‌های ناموفق Reset می‌شود.

تنظیم این مقادیر یک Trade-off واقعی بین امنیت و تجربه کاربری است. Threshold بسیار پایین می‌تواند Help Desk را با Ticketهای Lockout پر کند و حتی یک مهاجم را قادر کند با تولید Login Failure گسترده نوعی Denial of Service علیه کاربران ایجاد کند. Threshold بسیار بالا هم ممکن است فرصت بیشتری برای Password Guessing بدهد.

مایکروسافت در راهنمای Remediation به‌روزشده در ۲۷ مه ۲۰۲۶، مقدار ۱۰ تلاش ناموفق را به‌عنوان مقدار توصیه‌شده فعلی Security Compliance Toolkit برای Account Lockout Threshold مطرح می‌کند؛ اما این عدد نباید بدون بررسی Risk Profile، MFA، Fine-Grained Password Policy، نوع کاربران و الگوی واقعی Authentication سازمان کپی شود.

اول Symptom را از Root Cause جدا کنید

Event قفل شدن حساب خودش علت نیست. Event فقط می‌گوید تعداد تلاش‌های ناموفق به آستانه رسیده است.

برای مثال، اگر کاربر Password خود را ساعت ۹ تغییر دهد و ساعت ۹:۰۵ حسابش Lock شود، چند سناریوی متداول وجود دارد:

• یک Windows Service هنوز با Password قبلی اجرا می‌شود.
• Scheduled Task با Credential قدیمی ذخیره شده است.
• Mapped Drive یا Share با Credential Cache شده تلاش به اتصال می‌کند.
• یک Session قدیمی روی RDP یا VDI همچنان Credential قبلی را استفاده می‌کند.
• Outlook، VPN، Agent یا نرم‌افزار Legacy با Password قبلی Retry می‌کند.
• کاربر روی یک Laptop دوم یا سیستم شعبه Session باز دارد.
• یک Credential Manager Entry قدیمی در Windows باقی مانده است.
• حساب Service یا Admin روی چند Host استفاده شده و فقط روی یکی Password به‌روزرسانی نشده است.
• تلاش‌های ناموفق از یک IP یا Host ناشناس در حال تکرار است و باید به‌عنوان رخداد امنیتی بررسی شود.

بنابراین Unlock کردن حساب بدون یافتن Source معمولاً فقط چند دقیقه زمان می‌خرد.

Event IDهای مهم برای ریشه‌یابی Account Lockout

مایکروسافت Event 4740 را Event رسمی قفل شدن حساب معرفی می‌کند و فیلد Caller Computer Name را به‌عنوان نام کامپیوتری که Login Attempt از آن دریافت شده توضیح می‌دهد. نکته مهم این است که در همه سناریوها این فیلد الزاماً کامل نیست؛ به همین دلیل Correlation با 4625، 4771، 4776 و Timeline اطراف رخداد اهمیت دارد.

روش Native ویندوز برای پیدا کردن Source قفل شدن حساب

اگر ADAudit Plus در اختیار ندارید، مسیر Native معمولاً از Event Viewer شروع می‌شود:

1. Audit Policy لازم برای Account Management، Logon و Credential Validation را فعال کنید.
2. روی Domain Controllerها Event 4740 را پیدا کنید.
3. Account Name و Caller Computer Name را ثبت کنید.
4. روی Host مبدا، Eventهای 4625 و سایر Failureهای همان Timeline را بررسی کنید.
5. Windows Serviceها، Scheduled Taskها، Mapped Driveها، Credential Manager و Sessionهای قدیمی را بررسی کنید.
6. اگر Authentication از NTLM یا Kerberos آمده، Eventهای متناظر را Correlate کنید.
7. بعد از رفع Credential قدیمی، حساب را Unlock کنید و چند چرخه Authentication را Monitor کنید.

این روش برای یک Incident محدود قابل انجام است؛ اما وقتی چند Domain Controller، ده‌ها Server، شعب مختلف و صدها کاربر دارید، زمان تحلیل افزایش پیدا می‌کند و همین‌جا Centralized Auditing ارزش عملیاتی ایجاد می‌کند.

Account Lockout Analyzer در ADAudit Plus چه چیزی اضافه می‌کند؟

براساس مستندات فعلی ManageEngine، Account Lockout Analyzer در ADAudit Plus می‌تواند منبع Lockout را به ماشین، IP و حتی Component ویندوزی مرتبط کند؛ برای مثال Scheduled Task، Mapped Drive یا Service Account.

گزارش Lockout می‌تواند اطلاعاتی مانند این موارد را کنار هم قرار دهد:

• نام User قفل‌شده؛
• Domain Controller درگیر؛
• Caller Computer یا Source؛
• زمان دقیق Lockout؛
• Login Attemptهای قبلی؛
• Serviceها، Applicationها یا Driveهایی که Credential را استفاده کرده‌اند؛
• الگوی غیرعادی افزایش Lockoutها؛
• رویدادهای مربوط به حساب‌های Privileged.

این مزیت فقط «گزارش زیباتر» نیست. هدف این است که Time-to-Diagnosis کاهش پیدا کند و کارشناس مجبور نباشد برای هر Lockout مسیر دستی Event Viewer را از ابتدا تکرار کند.

سناریو ۱: Password عوض شده و حساب هر پنج دقیقه Lock می‌شود

این یکی از متداول‌ترین سناریوهاست.

فرض کنید کاربر Password خود را تغییر داده، اما روی یک Server قدیمی Scheduled Task با Credential قبلی ذخیره شده است. Task هر پنج دقیقه اجرا می‌شود، Login Failure ایجاد می‌کند و بعد از رسیدن به Threshold حساب Lock می‌شود.

مسیر بررسی پیشنهادی:

1. در ADAudit Plus گزارش Account Lockout را باز کنید.
2. Source Host را مشخص کنید.
3. Timeline قبل از Lockout را بررسی کنید.
4. روی Host مبدا Scheduled Task و Serviceهای Run As User را بررسی کنید.
5. Password ذخیره‌شده را Update یا Credential وابسته را حذف کنید.
6. بعد از اصلاح، Lockout Trend همان User را برای چند ساعت Monitor کنید.

اگر Source همیشه یک Host مشخص باشد، احتمال Credential Stale بسیار زیاد است. اگر Sourceها متغیر، ناشناس یا از ساعات غیرعادی باشند، مسیر Investigation باید امنیتی‌تر شود.

سناریو ۲: Mapped Drive یا Credential Manager

کاربر Password را تغییر داده اما Windows هنوز برای یک Share قدیمی از Credential Cache شده استفاده می‌کند. User شاید حتی آن Drive را هر روز باز نکند، ولی سیستم یا Application در پس‌زمینه Retry انجام می‌دهد.

در این حالت فقط Reset کردن Password مشکل را بدتر می‌کند، چون Credential قدیمی همچنان Retry می‌شود. باید Source مشخص شود و Entry قدیمی در Credential Manager، Mapped Drive یا Connection مربوط اصلاح شود.

در تیم‌های Help Desk بهتر است برای Lockoutهای تکرارشونده Runbook مشخص داشته باشید تا کارشناس بعد از دومین Lockout مستقیم سراغ Source Analysis برود و فقط Unlock مجدد انجام ندهد.

سناریو ۳: Service Account با Password قدیمی

Service Accountها ریسک بالاتری دارند، چون معمولاً روی چند Server و Application استفاده می‌شوند. اگر Password چنین حسابی تغییر کند اما فقط بخشی از سرویس‌ها Update شوند، Failureها می‌توانند از چند Host مختلف ایجاد شوند.

برای این نوع حساب‌ها بهتر است علاوه بر Lockout Analysis، Inventory مشخصی از Dependencyهای Credential داشته باشید. در بلندمدت هم استفاده از Managed Service Accountها، کاهش Password Sharing و طراحی اصولی Privileged Access می‌تواند ریسک را کمتر کند.

اگر حساب موردنظر Privileged است، Lockout را فقط یک Issue عملیاتی نبینید. حساب Admin که از Source غیرمنتظره Lock می‌شود می‌تواند نشانه Password Spray، Credential Misuse یا تلاش Automated باشد.

چطور Lockout معمولی را از رفتار امنیتی مشکوک جدا کنیم؟

ManageEngine در نسخه فعلی Account Lockout Examiner به قابلیت تشخیص Unusual Volume of Lockout براساس Baseline اشاره می‌کند. این قابلیت کمک می‌کند تیم امنیت فقط روی یک User تمرکز نکند و افزایش غیرعادی Lockout در سطح Domain را هم ببیند.

Alert برای حساب‌های حساس را جدا طراحی کنید

Lockout یک کاربر عادی و Lockout یک Domain Admin ارزش یکسانی ندارند.

برای حساب‌های حساس پیشنهاد می‌شود:

• Alert فوری Email/SMS یا کانال عملیاتی داشته باشید.
• Source Host و IP را همان لحظه بررسی کنید.
• Login Attemptهای قبل و بعد از Lockout را Correlate کنید.
• اگر Source ناشناس است، Host و Account را وارد Investigation امنیتی کنید.
• اگر سازمان SIEM دارد، Lockoutهای Privileged را به Use Caseهای Identity Threat متصل کنید.
• تکرار Lockout روی چند حساب حساس را به‌عنوان Pattern بررسی کنید، نه چند Ticket مستقل.

در کنار Auditing، کاهش Standing Privilege و MFA مقاوم‌تر اهمیت دارد. برای همین موضوع، مقاله Passkey و FIDO2 در ADSelfService Plus می‌تواند مکمل خوبی برای لایه Authentication باشد.

Account Lockout و Service Desk؛ Ticket باید چه اطلاعاتی داشته باشد؟

اگر هر Lockout فقط با Subject «کاربر نمی‌تواند Login کند» ثبت شود، بعداً هیچ Pattern قابل اتکایی برای Problem Management ندارید.

برای Ticketهای Lockout حداقل این داده‌ها مفید هستند:

• User Account؛
• Time of Lockout؛
• Source Host/IP؛
• Event IDهای کلیدی؛
• آیا Password اخیراً تغییر کرده؟
• آیا Service/Scheduled Task پیدا شد؟
• آیا حساب Privileged است؟
• Root Cause نهایی؛
• Permanent Fix؛
• تعداد دفعات تکرار در ۳۰ روز اخیر.

ManageEngine اعلام می‌کند ADAudit Plus می‌تواند Alertهای Lockout را به ابزارهای Ticketing از جمله ServiceDesk Plus متصل کند. این موضوع وقتی ارزش بیشتری پیدا می‌کند که Lockoutهای تکرارشونده به Problem Record تبدیل شوند، نه اینکه هر بار یک Incident مستقل بسته شود. برای مطالعه ساختار Incident Management می‌توانید از راهنمای Incident Management در ServiceDesk Plus استفاده کنید.

Policy Lockout را فقط برای کم کردن Ticket ضعیف نکنید

وقتی تعداد Lockout زیاد می‌شود، یک واکنش اشتباه این است که Threshold را بدون تحلیل علت بالا ببریم یا Lockout را عملاً غیرفعال کنیم.

اگر علت اصلی Credential Stale باشد، تغییر Policy فقط علامت را پنهان می‌کند. اگر علت Password Spray باشد، Policy ضعیف‌تر حتی می‌تواند دفاع را کاهش دهد.

مایکروسافت در راهنمای ۲۰۲۶ خود تأکید می‌کند Threshold باید تعادلی بین User Error و Brute Force ایجاد کند و در عین حال Account Lockout Duration هم باید طوری طراحی شود که خطر DoS عملیاتی کنترل شود. بنابراین تصمیم Policy باید مبتنی بر داده واقعی Lockout، MFA، Risk حساب‌ها و Fine-Grained Password Policy باشد.

Fine-Grained Password Policy را فراموش نکنید

در Active Directory ممکن است همه کاربران از یک Lockout Policy واحد پیروی نکنند. اگر Password Settings Object یا Fine-Grained Password Policy دارید، Account Lockout رفتار متفاوتی برای گروه‌های خاص خواهد داشت.

این موضوع در Troubleshooting مهم است، چون دو کاربر در یک Domain ممکن است بعد از تعداد متفاوتی Login Failure Lock شوند. قبل از نتیجه‌گیری درباره «اشتباه بودن Policy» ابتدا Effective Policy حساب را بررسی کنید.

KPIهای مفید برای مدیریت Account Lockout

اگر ADAudit Plus را فقط برای حل موردی Lockout استفاده کنید، بخشی از ارزش آن را از دست می‌دهید. بهتر است روندها هم اندازه‌گیری شوند.

هدف نهایی صفر کردن Lockout نیست؛ Lockout بخشی از مکانیزم دفاعی Authentication است. هدف این است که Lockout غیرضروری و تکرارشونده کم شود و Lockout مشکوک سریع‌تر دیده شود.

ADAudit Plus را فقط ابزار Lockout نبینید

Account Lockout Analyzer یکی از Use Caseهای ملموس ADAudit Plus است، اما محصول برای Auditing تغییرات Active Directory، Logon Monitoring، File Server Auditing، Microsoft Entra ID، Microsoft 365، Compliance Reporting و تشخیص Misconfiguration نیز استفاده می‌شود.

اگر می‌خواهید دید کلی‌تری از محصول داشته باشید، صفحه نظارت هوشمند بر امنیت اکتیودایرکتوری و Money Page اصلی ManageEngine ADAudit Plus را ببینید.

نسخه و Hardening خود ADAudit Plus هم مهم است

ابزار Audit خودش بخشی از Security Infrastructure است و باید به‌روز نگه داشته شود. Release Notes رسمی ManageEngine نشان می‌دهد Build 8710 در ۳۰ ژوئیه ۲۰۲۶ منتشر شده و در Buildهای ۲۰۲۶ چند اصلاح امنیتی و بهبود ارتباط Agent-to-Server اعمال شده است. بنابراین در کنار طراحی Use Caseهای Auditing، Patch و Upgrade خود ADAudit Plus را هم در Change Management نگه دارید.

Checklist عملی برای Troubleshooting قفل شدن حساب

1. زمان دقیق Lockout را ثبت کنید.
2. Event 4740 و Caller Computer را بررسی کنید.
3. Eventهای 4625، 4771 و 4776 همان Timeline را Correlate کنید.
4. بررسی کنید Password اخیراً تغییر کرده یا نه.
5. Serviceها و Scheduled Taskهای Source Host را بررسی کنید.
6. Mapped Drive و Credential Manager را بررسی کنید.
7. Sessionهای RDP/VDI و دستگاه‌های دوم کاربر را بررسی کنید.
8. اگر حساب Service است، Dependency همه Hostها را بررسی کنید.
9. اگر حساب Privileged یا Source ناشناس است، Incident امنیتی باز کنید.
10. Permanent Fix را ثبت کنید؛ فقط Unlock نکنید.
11. تکرار Lockout را بعد از Fix Monitor کنید.
12. اگر Lockoutهای سازمان زیاد است، Baseline و Trend را بررسی کنید.

چه زمانی استفاده از ADAudit Plus توجیه بیشتری دارد؟

Native Event Viewer برای یک Domain کوچک یا یک Incident موردی قابل استفاده است. اما ADAudit Plus زمانی ارزش بیشتری ایجاد می‌کند که یکی از این شرایط وجود داشته باشد:

• چند Domain Controller و Site دارید؛
• تعداد Lockoutهای Help Desk زیاد است؛
• حساب‌های Privileged باید Real-time Monitor شوند؛
• Audit Trail برای Compliance لازم دارید؛
• Hybrid Identity شامل Entra ID و Microsoft 365 دارید؛
• نیاز به Alert و Ticket Automation دارید؛
• تحلیل Manual Event Log زمان تیم را می‌گیرد؛
• می‌خواهید Lockout Spike و رفتار غیرعادی را در سطح Domain ببینید.

سخن پایانی

قفل شدن حساب Active Directory معمولاً با یک Unlock ساده حل به نظر می‌رسد، اما اگر Source پیدا نشود، همان User دوباره به Help Desk برمی‌گردد. رویکرد حرفه‌ای این است که Account Lockout را مثل یک Signal ببینیم: Event 4740 نقطه شروع است، اما Root Cause ممکن است Scheduled Task، Service، Credential Cache، NTLM/Kerberos Failure یا حتی رفتار امنیتی مشکوک باشد.

ADAudit Plus این Investigation را از جستجوی پراکنده در Event Viewer به یک Workflow متمرکز نزدیک می‌کند و می‌تواند Source، Timeline، Login Attemptهای قبلی و Patternهای غیرعادی Lockout را کنار هم قرار دهد.

اگر قصد دارید ADAudit Plus را برای Active Directory Auditing، Lockout Analysis، Compliance یا Identity Security ارزیابی کنید، مدانت خدمات استعلام و تهیه لایسنس ManageEngine، استقرار، آموزش و پشتیبانی ارائه می‌کند. برای بررسی Scope واقعی محیط، تعداد Domain Controllerها، File Serverها و نیازهای Audit نیز می‌توانید از مسیر درخواست جلسه و دمو استفاده کنید.

منابع

• ManageEngine – Trace and diagnose account lockout in AD
• ManageEngine – Account Lockout Examiner
• ManageEngine ADAudit Plus Release Notes
• Microsoft – Account lockout threshold recommendation
• Microsoft – Event 4740