کاربر دورکار پشت لپتاپ سازمانی نشسته است، رمز Active Directory را فراموش کرده و به شبکه داخلی هم دسترسی ندارد. Help Desk رمز را در Domain Controller تغییر میدهد، اما مشکل حل نمیشود: لپتاپ هنوز Credential قبلی را در Cache محلی دارد و کاربر نمیتواند با رمز جدید وارد Windows شود.
این سناریو تفاوت مهم میان «Reset شدن رمز در Active Directory» و «قابل استفاده شدن همان رمز روی دستگاه دورکار» را نشان میدهد. Cached Credentials Update در ManageEngine ADSelfService Plus برای پوشاندن همین شکاف طراحی شده است. کاربر میتواند از صفحه ورود Windows هویت خود را تأیید کند، رمز دامنه را Reset کند و سپس Credential ذخیرهشده روی سیستم نیز بهروزرسانی شود؛ این فرآیند میتواند با VPN یا در شرایط مشخص بدون VPN انجام شود.
Cached Credentials چیست و چرا Windows به آن نیاز دارد؟
وقتی یک کاربر Domain-joined در شرایط دسترسی به Domain Controller وارد Windows میشود، اطلاعات لازم برای احراز هویت آفلاین بهصورت امن در سیستم Cache میشود. در دفعات بعد، اگر لپتاپ خارج از شبکه سازمان باشد، Windows میتواند ورود کاربر را با Credential محلی Cacheشده اعتبارسنجی کند. این قابلیت برای سفر و دورکاری ضروری است؛ اما اگر Password در Active Directory تغییر کند، Cache محلی الزاماً همان لحظه بهروزرسانی نمیشود.
مشکل کلاسیک بعد از Password Reset
| محل Credential | قبل از Reset | بعد از Reset در AD |
|---|---|---|
| Domain Controller | رمز قدیمی | رمز جدید |
| Cache محلی Windows | رمز قدیمی | هنوز رمز قدیمی |
در نتیجه کاربر ممکن است Password جدید را داشته باشد اما نتواند با آن وارد همان لپتاپ شود. برای نیروی دورکار این وضعیت میتواند عملاً به Lockout از Endpoint منجر شود.
ADSelfService Plus چگونه Cache را بهروزرسانی میکند؟
طبق مستندات رسمی ManageEngine، ADSelfService Plus با Windows Login Agent گزینه Reset Password/Unlock Account را در صفحه ورود Windows در اختیار کاربر قرار میدهد. کاربر ابتدا هویت خود را با MFA مجاز تأیید میکند، Password Reset انجام میشود و سپس Cached Credential روی دستگاه میتواند بهروزرسانی شود. قابلیت Cached Credentials Update در Edition حرفهای ADSelfService Plus ارائه میشود.
دو روش اصلی: با VPN یا بدون VPN
| روش | ارتباط مستقیم با AD | کاربرد | نکته مهم |
|---|---|---|---|
| Update via VPN | بله | سازمان دارای VPN سازگار | روش ترجیحی در صورت وجود زیرساخت مناسب |
| Update without VPN | خیر | نبود VPN یا VPN ناسازگار | باید محدودیتهای DPAPI بررسی شود |
روش اول: Cached Credentials Update با VPN
در مدل VPN، جریان عملیاتی چنین است:
- کاربر از Windows Login Agent گزینه Reset Password را انتخاب میکند.
- هویت کاربر با MFA تأیید میشود.
- رمز جدید در Active Directory ثبت میشود.
- Login Agent از طریق VPN ارتباط با شبکه سازمان را برقرار میکند.
- Cache محلی Windows با Password جدید همگام میشود.
در مستندات ManageEngine برای این سناریو از VPNهایی مانند Cisco AnyConnect، Fortinet، Windows Native VPN، SonicWall، Check Point و OpenVPN نام برده شده است. در سازمانی که VPN پایدار دارد، این مدل معمولاً انتخاب کمریسکتری است چون Endpoint در زمان Update با Domain Context ارتباط دارد.
روش دوم: بهروزرسانی Cached Credentials بدون VPN
ManageEngine از Build 6503 که در ۵ اوت ۲۰۲۴ منتشر شد، امکان Update کردن Cached Credentials بدون VPN را اضافه کرد. در این مدل کاربر هویت خود را تأیید میکند، Password دامنه Reset میشود و Login Agent بدون ایجاد Tunnel VPN، Cache محلی Windows را بهروزرسانی میکند.
این گزینه برای سازمانهایی مفید است که VPN ندارند یا Vendor مورد استفاده آنها با مکانیزم موردنیاز محصول سازگار نیست. با این حال، خود ManageEngine توصیه میکند اثر این روش بر دادههای وابسته به Windows DPAPI پیش از Rollout بررسی شود.
محدودیت مهم بدون VPN: DPAPI
Windows Data Protection API یا DPAPI برای حفاظت از برخی Secretهای کاربر استفاده میشود. مستندات ManageEngine هشدار میدهند که Update کردن Cache بدون اتصال به AD میتواند دسترسی به برخی دادههای محافظتشده را تا زمان اتصال بعدی دستگاه به Domain تحت تأثیر قرار دهد.
- Password و Auto-complete ذخیرهشده در برخی مرورگرها؛
- Credentialهای ذخیرهشده در Credential Manager؛
- Private Keyهای مرتبط با EFS؛
- برخی Certificateها و Secretهای کاربری.
بنابراین «بدون VPN» فقط یک گزینه سادهتر نیست؛ باید برای گروههای حساس Pilot جداگانه داشته باشد.
اگر هر دو روش فعال باشند چه میشود؟
طبق راهنمای ADSelfService Plus، وقتی هر دو روش فعال باشند، محصول ابتدا تلاش میکند Update را از طریق VPN انجام دهد و در صورت Failure، روش بدون VPN را بهعنوان Fallback امتحان میکند. برای نیروی Hybrid این طراحی مفید است، اما باید مشخص شود چه Endpointهایی اجازه استفاده از Fallback بدون VPN را دارند.
پیشنیازهای Rollout
- Windows Login Agent روی Endpointهای هدف نصب و سالم باشد.
- کاربران Enrollment کامل در ADSelfService Plus داشته باشند.
- MFA برای Self-Service Password Reset فعال باشد.
- Policyها روی OU/Group درست Scope شوند.
- Access URL محصول از بیرون شبکه امن و در دسترس باشد.
- Certificate معتبر استفاده شود.
- در مدل بدون VPN، وابستگیهای DPAPI ارزیابی شوند.
Rollout مرحلهای پیشنهادی
۱. Pilot واقعی بسازید
Pilot فقط روی تیم IT نباشد. کاربرانی با VPN، بدون VPN، Credential Manager، EFS و الگوهای مختلف دورکاری را وارد آزمون کنید.
۲. Password Expiry را هم تست کنید
مشکل فقط Forgotten Password نیست. Password Expiration برای کاربری که مدت زیادی خارج از شبکه بوده نیز میتواند همان شکاف Cache را ایجاد کند. Notification قبل از انقضا و Self-Service Change تعداد Ticketها را کم میکند.
۳. Failure Path داشته باشید
اگر Update شکست خورد، Help Desk باید Runbook مشخصی برای بررسی Login Agent، Enrollment، Connectivity، VPN و Policy داشته باشد.
KPIهای مناسب
| KPI | هدف |
|---|---|
| Password Reset Success Rate | موفقیت Self-Service |
| Cached Credential Update Success Rate | تفکیک Reset از Cache Sync |
| Remote Lockout Tickets | کاهش Ticket دورکاری |
| Help Desk Assisted Reset Rate | سنجش وابستگی به کارشناس |
| Login Agent Coverage | درصد Endpointهای آماده |
| Fallback without VPN Rate | تشخیص ضعف مسیر VPN |
ارتباط Cached Credentials با MFA
Self-Service Password Reset بدون Identity Verification قوی خودش میتواند مسیر Account Takeover باشد. مقاله MFA ضد فیشینگ با ADSelfService Plus طراحی FIDO2، Passkey و Conditional Access را بررسی میکند. هدف این است که فردی که Password را Reset میکند واقعاً مالک Identity باشد.
ارتباط با Help Desk و Self-Service
هر Reset که بدون تماس با Help Desk تکمیل شود و کاربر بعد از آن واقعاً بتواند وارد Endpoint شود، یک زنجیره پشتیبانی را کوتاه میکند. برای طراحی تجربه Self-Service نیز راهنمای Self-Service Portal در سایت تخصصی مدانت مفید است.
لایسنس و Edition
Cached Credentials Update در جدول رسمی Editionهای ADSelfService Plus در Professional قرار دارد. برای جلوگیری از انتخاب Edition نامناسب، مقاله لایسنس ADSelfService Plus؛ محاسبه تعداد User، Edition و Endpoint MFA را پیش از خرید یا تمدید ببینید.
نکات کلیدی
- Password Reset در AD بهتنهایی تضمین نمیکند کاربر دورکار با Password جدید وارد Windows شود.
- ADSelfService Plus میتواند Cache را از Windows Login Screen بهروزرسانی کند.
- روش VPN در صورت وجود زیرساخت سازگار انتخاب ترجیحی است.
- روش بدون VPN مفید است اما محدودیت DPAPI باید ارزیابی شود.
- Login Agent، Enrollment و MFA پیشنیازهای اصلی هستند.
- موفقیت Reset و Cache Update باید دو KPI جدا باشند.
منابع رسمی
- ManageEngine ADSelfService Plus Features
- ADSelfService Plus Release Notes
- Update Windows Cached Credentials
سخن پایانی
در دورکاری، Reset شدن Password فقط نصف مسئله است. اگر Credential جدید به Cache محلی Windows نرسد، کاربر همچنان پشت صفحه Login متوقف میشود. ADSelfService Plus با Cached Credentials Update این فاصله را پوشش میدهد و امکان اجرای سناریو با VPN یا در شرایط مشخص بدون VPN را فراهم میکند.
مدانت خدمات خرید و تمدید لایسنس، طراحی SSPR و MFA، استقرار Login Agent، Hardening، آموزش و پشتیبانی ADSelfService Plus را ارائه میدهد. برای طراحی Rollout سازمانی یا دریافت پیشنهاد لایسنس میتوانید از مشاوره مدانت استفاده کنید.
