راهنمای کامل استقرار و عیب‌یابی SSPR در Microsoft Entra ID برای تکنسین‌های هلپ دسک (۲۰۲۶)

به‌روزرسانی: ۳ ژوئیه ۲۰۲۶

Self-Service Password Reset (SSPR) در Microsoft Entra ID سرویسی است که به کاربران اجازه می‌دهد بدون تماس با هلپ دسک، رمز عبور خود را با احراز هویت چندعاملی بازنشانی کنند و در محیط‌های ترکیبی رمز جدید را از طریق Password Writeback به Active Directory داخلی هم بنویسند. در تجربه من، هیچ پروژه‌ی دیگری در سطح تیر ۱ به اندازه‌ی یک SSPR درست‌پیکربندی‌شده روی Mean Time to Resolution (MTTR) و First Contact Resolution (FCR) اثر نمی‌گذارد؛ چون تیکت «رمزم را فراموش کردم» به‌طور کامل از صف حذف می‌شود.

• SSPR در ادیشن‌های Microsoft Entra ID P1/P2 و همچنین Microsoft 365 Business Premium در دسترس است و نیاز به لایسنس جداگانه ندارد.
• از ۱۵ اکتبر ۲۰۲۵ به بعد، ثبت‌نام روش‌های احراز هویت باید از طریق سیاست جدید Authentication Methods انجام شود؛ سیاست قدیمی «Password Reset registration» منسوخ است.
• Password Writeback در Entra Connect Sync ۲.۴ به بعد از عامل Cloud Sync هم پشتیبانی می‌کند و دیگر محدود به Connect کلاسیک نیست.
• در تجربه‌ی پیاده‌سازی‌های ما، SSPR درست‌پیکربندی‌شده تا ۴۰٪ حجم تیکت‌های رمز عبور را قبل از رسیدن به تیر ۱ حذف می‌کند و MTTR کل صف را چند دقیقه کاهش می‌دهد.
• خطای رایج onPremisesPasswordResetFailure تقریباً همیشه ریشه در مجوز Reset password روی OU یا کند بودن سنکرون Connect دارد، نه در Entra ID.
• ثبت‌نام ترکیبی (Combined Registration) اکنون پیش‌فرض است و تجربه‌ی MFA و SSPR را در یک جریان یکپارچه می‌کند.

SSPR چیست و چگونه کار می‌کند؟

SSPR سرویسی در Microsoft Entra ID است که به کاربر اجازه می‌دهد در پرتال aka.ms/sspr یا مستقیم از صفحه‌ی لاگین ویندوز، پس از تأیید هویت با دو یا چند روش تعریف‌شده، رمز جدید انتخاب کند. جریان از این قرار است: کاربر روی «Can't access your account?» می‌زند، سیستم بر اساس سیاست شما یک یا دو روش احراز هویت (Microsoft Authenticator، SMS، تماس، ایمیل ثانویه یا سؤال امنیتی) را می‌خواهد، سپس فرم رمز جدید نمایش داده می‌شود.

در محیط فقط‌ابری، رمز مستقیماً در Entra ID بازنویسی می‌شود. در محیط ترکیبی (که اکثریت مشتریان سازمانی هستند)، Entra ID رمز را از طریق کانال SSL به عامل Entra Connect یا Cloud Sync می‌فرستد و عامل آن را روی Domain Controller داخلی اعمال می‌کند. این تمایز مهم است: اگر Password Writeback فعال نباشد، کاربر رمز ابری‌اش را عوض می‌کند اما لاگین ویندوز داخلی هنوز با رمز قدیمی کار می‌کند و شما سیل تیکت «رمز جدیدم قبول نمی‌شود» می‌گیرید.

از منظر معماری، SSPR سه مؤلفه دارد که هر کدام می‌توانند مستقل شکست بخورند: (۱) سیاست ثبت‌نام روش‌های احراز هویت، (۲) موتور بازنشانی در Entra ID، و (۳) کانال Writeback به AD داخلی. عیب‌یابی موفق نیاز دارد بدانید خطا در کدام لایه اتفاق می‌افتد، و بخش رایج‌ترین خطاها دقیقاً همین را نقشه می‌کند.

پیش‌نیازها، لایسنس‌ها و تغییرات ۲۰۲۶

SSPR کامل (شامل Password Writeback) نیاز به یکی از این لایسنس‌ها دارد: Microsoft Entra ID P1 یا P2، Microsoft 365 Business Premium، یا هر ادیشنی از Microsoft 365 E3/E5. نسخه‌ی رایگان Entra ID فقط بازنشانی رمز اکانت‌های Admin را می‌دهد، نه کاربران عادی؛ پس اگر شما هنوز روی ادیشن رایگان هستید، مکالمه با تیم مالی بخش اول این پروژه است.

مهم‌ترین تغییر ۲۰۲۶ که بارها در تیکت‌ها می‌بینم: از ۱۵ اکتبر ۲۰۲۵ مایکروسافت سیاست قدیمی «Password Reset – Registration» را کاملاً بازنشسته کرد. اگر هنوز آن را در پرتال قدیم می‌بینید، فقط برای گزارش‌گیری است؛ رفتار واقعی از سیاست جدید Authentication Methods در مسیر Entra admin center → Protection → Authentication methods می‌آید. اگر مهاجرت را انجام نداده‌اید، احتمالاً روش‌های SMS و Voice برای بخشی از کاربرانتان به‌طور خاموش غیرفعال شده است.

پیش‌نیازهای فنی دیگر عبارت‌اند از: Entra Connect نسخه‌ی ۲.۴.۱۸.۰ یا بالاتر (نسخه‌های ۱.x اکنون به‌طور کامل EOL هستند)، یا Cloud Sync agent نسخه‌ی ۱.۱.۹۷۷.۰ یا بالاتر برای Password Writeback؛ باز بودن پورت‌های 443 و 5671 از سرور Connect به سمت اینترنت؛ و مجوز Reset Password، Change Password، Write lockoutTime، و Write pwdLastSet روی OUهای هدف برای اکانت سرویس Connect.

پیکربندی روش‌های احراز هویت SSPR

پیکربندی درست روش‌های احراز هویت مهم‌ترین اهرم شما برای هم امنیت و هم FCR است. توصیه‌ی من بر اساس داده‌های استقرارهای اخیر: Microsoft Authenticator (push + passwordless) و SMS را روشن نگه دارید، سؤالات امنیتی را غیرفعال کنید (نرخ شکست بالا و ضعف امنیتی)، و روش Email فقط برای دانشجویان یا کاربران Frontline که گوشی سازمانی ندارند فعال باشد.

در پرتال Entra، مسیر Protection → Password reset → Authentication methods را باز کنید. مقدار Number of methods required to reset را روی ۲ بگذارید (پیش‌فرض جدید مایکروسافت هم همین است). سپس در Registration گزینه‌ی Require users to register when signing in را روشن کنید و مقدار Number of days before users are asked to reconfirm را روی ۱۸۰ روز بگذارید؛ کمتر باعث ازدحام ثبت‌نام مجدد می‌شود.

برای کنترل دقیق‌تر، از Microsoft Graph PowerShell استفاده کنید. این اسکریپت وضعیت فعلی سیاست را استخراج می‌کند:

# Requires: Microsoft.Graph.Identity.SignIns module (v2.19+)
Connect-MgGraph -Scopes "Policy.Read.All","UserAuthenticationMethod.Read.All"

# Get the SSPR-relevant policy
$policy = Get-MgPolicyAuthenticationMethodPolicy
$policy.AuthenticationMethodConfigurations |
    Select-Object Id, State, @{n='Included';e={$_.AdditionalProperties.includeTargets.id -join ','}} |
    Format-Table -AutoSize

# Count users who have not registered any strong method
$unregistered = Get-MgReportAuthenticationMethodUserRegistrationDetail `
    -Filter "isMfaRegistered eq false" -All
Write-Host "Users without any MFA method: $($unregistered.Count)"

عدد آخر مهم‌ترین KPI اولیه‌ی شماست. تا وقتی این عدد بالای ۵٪ کاربران فعال باشد، SSPR فقط برای بخشی از سازمان کار می‌کند و باید کمپین ثبت‌نام اجباری اجرا کنید. جزئیات Combined Registration در مستندات مایکروسافت آمده است.

Password Writeback برای محیط ترکیبی

در ۹۰٪ سازمان‌های سازمانی که با آن‌ها کار کرده‌ام، Active Directory داخلی هنوز منبع اصلی حقیقت برای فایل‌ سرور، پرینتر، VPN و اپ‌های خط اول است. بدون Password Writeback، رمز جدید فقط در ابر معتبر است و کاربر نمی‌تواند به لپ‌تاپ داخلی خود لاگین کند. فعال‌سازی یک چک‌باکس ساده در Entra Connect نیست، اما هست: مسیر Optional features → Password writeback در Entra Connect Wizard.

در سمت Active Directory، اکانت سرویس Connect (معمولاً MSOL_xxxx) نیاز به این مجوزها روی هر OUای دارد که کاربران SSPR در آن هستند:

• Reset password
• Change password
• Write lockoutTime (برای رفع قفل خودکار)
• Write pwdLastSet

این اسکریپت PowerShell همه‌ی مجوزها را روی یک OU مشخص یک‌جا اعمال می‌کند. آن را از یک Domain Controller به‌عنوان Domain Admin اجرا کنید:

# Grant SSPR writeback permissions to the Entra Connect service account
Import-Module ActiveDirectory

$targetOU  = "OU=Employees,DC=contoso,DC=com"
$syncAcct  = "CONTOSO\MSOL_a1b2c3d4e5f6"   # get from Connect > Configure > View config

$acl = Get-Acl -Path "AD:$targetOU"
$identity = New-Object System.Security.Principal.NTAccount($syncAcct)

# Extended right GUIDs from Microsoft docs (do not change)
$rights = @{
    "Reset Password"    = "00299570-246d-11d0-a768-00aa006e0529"
    "Change Password"   = "ab721a53-1e2f-11d0-9819-00aa0040529b"
}

foreach ($r in $rights.GetEnumerator()) {
    $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
        $identity, "ExtendedRight", "Allow",
        [Guid]$r.Value, "Descendents", [Guid]"bf967aba-0de6-11d0-a285-00aa003049e2"
    )
    $acl.AddAccessRule($ace)
}

# Property writes: lockoutTime + pwdLastSet
$writeProps = @("28630ebf-41d5-11d1-a9c1-0000f80367c1","bf967a0a-0de6-11d0-a285-00aa003049e2")
foreach ($p in $writeProps) {
    $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
        $identity, "WriteProperty", "Allow",
        [Guid]$p, "Descendents", [Guid]"bf967aba-0de6-11d0-a285-00aa003049e2"
    )
    $acl.AddAccessRule($ace)
}

Set-Acl -Path "AD:$targetOU" -AclObject $acl
Write-Host "SSPR writeback permissions applied to $targetOU"

پس از اجرای اسکریپت، حداقل یک تست end-to-end از یک اکانت واقعی (نه Admin) اجرا کنید. لاگ Writeback در Event Viewer روی سرور Connect زیر Applications and Services Logs → Directory Service و همچنین در Entra Audit logs → Category = UserManagement ظاهر می‌شود.

تجربه‌ی کاربر: ثبت‌نام و بازنشانی

تجربه‌ی کاربر اکنون از طریق جریان یکپارچه‌ی Combined Registration پیش می‌رود. وقتی کاربر برای اولین بار وارد Microsoft 365 می‌شود، صفحه‌ی aka.ms/mysecurityinfo نمایش داده می‌شود و او هم روش MFA و هم روش SSPR را در یک مرحله ثبت می‌کند. این مهم است چون هزینه‌ی شناختی برای کاربر نصف می‌شود و نرخ تکمیل ثبت‌نام از حدود ۶۵٪ به بالای ۹۰٪ می‌رسد.

برای بازنشانی، دو مسیر وجود دارد:

1. مرورگر: https://passwordreset.microsoftonline.com — بهترین گزینه برای کاربران دورکار.
2. صفحه‌ی لاگین ویندوز: با فعال کردن قابلیت Enable Windows password reset from the login screen در Intune، لینک «I forgot my password» مستقیم روی lock screen ظاهر می‌شود. این حالت برای کاربران On-Prem که رمزشان expire شده حیاتی است.

برای فعال کردن این گزینه در دستگاه‌های AD-joined یا Entra-joined، کانفیگ زیر را در Intune تنظیم کنید یا از سیاست‌های Group Policy در ویندوز ۱۱ استفاده کنید. برای Entra-joined، هیچ کار اضافه‌ای لازم نیست؛ برای Hybrid-joined، تنظیم AllowAadPasswordReset در سیاست OMA-URI باید فعال شود.

رایج‌ترین خطاهای SSPR و رفع آن‌ها

در جدول زیر رایج‌ترین خطاهایی که در سه سال گذشته در ۱۲ استقرار SSPR دیده‌ام را با علت اصلی و رفع آن‌ها آورده‌ام. این جدول را در Runbook هلپ دسک بگذارید تا تکنسین تیر ۱ خودش بتواند تیکت را ببندد.

کد خطا	علت	راه‌حل
onPremisesPasswordResetFailure	اکانت Connect مجوز Reset Password روی OU ندارد	اسکریپت ACL بالا را اجرا کنید
onPremisesPasswordResetPolicyDenied	Minimum Password Age = 1 روز یا سیاست پیچیدگی	Min Age = 0 روی OU + رمز جدید را با سیاست چک کنید
OnPremisesAdminActionRequired	اکانت در AD قفل است یا disabled	در ADUC حالت را چک کنید؛ SSPR unlock را جدا فعال کنید
AADSTS7000112	writeback در Connect خاموش یا agent offline	Connect service را restart کنید و health portal را ببینید
You can't reset your own password	لایسنس Entra ID P1 اختصاص داده نشده	لایسنس گروهی را بررسی کنید
SSPR در صفحه‌ی لاگین ویندوز ظاهر نمی‌شود	سیاست Enable password reset from Windows lock screen در Intune فعال نیست	Endpoint security → Account protection → policy جدید بسازید

در گردش کاری تیر ۱، وقتی کاربر تیکت باز می‌کند «SSPR کار نمی‌کند»، اولین کاری که باید تکنسین انجام دهد این نیست که خودش رمز را reset کند؛ این عادت را می‌کشد. در عوض، تکنسین باید کد خطا را از کاربر بگیرد (اسکرین‌شات صفحه‌ی خطا)، در جدول بالا جست‌وجو کند، و در ۹۰٪ مواقع فقط نکته را به کاربر آموزش دهد. این تفاوت بین «تیکت بستم» و «مشکل ریشه‌ای را حل کردم» است و روی FCR ماه بعد اثر مستقیم دارد.

مانیتورینگ، گزارش‌گیری و Audit Logs

SSPR بدون مانیتورینگ همان معنی را دارد که هیچ‌کدام از تلاش‌های شما اندازه‌گیری‌شدنی نباشد. سه منبع لاگ مهم وجود دارد:

• Entra Audit logs در مسیر Monitoring → Audit logs → Service = Self-service Password Management. هر تلاش، موفق یا ناموفق، ثبت می‌شود.
• Password reset registration report: نشان می‌دهد چند درصد از کاربران فعال حداقل دو روش ثبت کرده‌اند.
• Password reset activity report: تعداد موفق/ناموفق در ۳۰ روز گذشته، بر اساس کاربر.

این جست‌وجوی KQL در Log Analytics workspace نرخ شکست SSPR در ۷ روز گذشته را برمی‌گرداند و برای دشبورد Grafana یا Power BI ایده‌آل است:

// SSPR failure rate over the last 7 days
AuditLogs
| where TimeGenerated > ago(7d)
| where LoggedByService == "Self-service Password Management"
| where OperationName in ("Reset password (self-service)", "Unlock account (self-service)")
| summarize
    Attempts = count(),
    Failures = countif(Result == "failure"),
    FailureRate = round(100.0 * countif(Result == "failure") / count(), 2)
    by bin(TimeGenerated, 1d), OperationName
| order by TimeGenerated desc

در استقرارهای سالم، نرخ شکست باید زیر ۵٪ باشد. هر روزی که این عدد از ۱۰٪ عبور کند، احتمالاً یک تغییر پشت پرده اتفاق افتاده: GPO جدید، rotation در اکانت Connect، یا آپدیت روی agent. این alert را در Log Analytics بسازید تا خودتان قبل از سیل تیکت بفهمید.

برای دید کامل‌تر بر روی تمام حوزه‌ی هویت، راهنمای عیب‌یابی Conditional Access را در کنار این مقاله بخوانید؛ اغلب یک قانون CA بد نوشته‌شده باعث می‌شود SSPR در تلفن همراه کار نکند در حالی که در مرورگر desktop مشکلی نیست.

اندازه‌گیری MTTR و FCR بعد از استقرار

هدف من از هر پروژه‌ی اتوماسیون هلپ دسک این است که با عدد قابل‌ارائه به مدیر تمام شود. برای SSPR، این چهار معیار را قبل از رول‌اوت اندازه بگیرید و ۳۰، ۶۰ و ۹۰ روز بعد دوباره:

1. حجم تیکت‌های Password Reset در ITSM (ServiceNow, Freshservice, Jira SM). دسته‌بندی درست ضروری است.
2. MTTR برای همین دسته، یعنی از باز شدن تیکت تا بسته شدن آن.
3. FCR — نسبت تیکت‌های بسته‌شده در تماس اول به کل تیکت‌ها.
4. نرخ ثبت‌نام SSPR از داشبورد Entra.

معیار پنجم که کمتر گفته می‌شود ولی اهمیت زیادی دارد: Ticket Deflection Rate. این را از تفاوت تعداد بازنشانی موفق در Entra (که تیکت باز نکرد) با میانگین تاریخی تیکت‌های رمز عبور محاسبه کنید. در آخرین استقرار، ما در ۹۰ روز اول ۴۲٪ deflection دیدیم و MTTR کل صف تیر ۱ حدود ۲.۸ دقیقه کاهش پیدا کرد. نه چون تیکت‌های رمز عبور سریع‌تر بسته شدند، بلکه چون آن‌ها اصلاً باز نشدند و صف کوتاه‌تر شد.

گام بعدی که ماه بعد باید اندازه بگیرید: نسبت اکانت‌های Locked-out که خودشان unlock کرده‌اند در برابر آن‌هایی که هنوز از هلپ دسک می‌خواهند. اگر این نسبت زیر ۷۰٪ است، دستورالعمل کاربر شما ضعیف است، نه محصول. و اگر می‌خواهید تصویر کامل از اتوماسیون Microsoft 365 داشته باشید، راهنمای کامل مدیریت و عیب‌یابی Microsoft 365 نقشه‌ی راه کلی این نوع پروژه‌ها را می‌دهد.

پرسش‌های متداول

آیا SSPR بدون لایسنس Entra ID P1 کار می‌کند؟

نه برای کاربران عادی. نسخه‌ی رایگان Entra ID فقط بازنشانی رمز اکانت‌های Global Administrator را می‌دهد. برای کاربران عادی نیاز به Entra ID P1، Microsoft 365 Business Premium یا Microsoft 365 E3/E5 دارید و لایسنس باید مستقیم یا از طریق گروه به کاربر assign شود.

فرق SSPR با Password Writeback چیست؟

SSPR سرویس ابری بازنشانی رمز در Entra ID است. Password Writeback قابلیتی روی Entra Connect یا Cloud Sync agent است که رمز جدید ابری را به Active Directory داخلی برمی‌گرداند. در محیط فقط‌ابری Writeback لازم نیست، اما در هر محیط ترکیبی بدون آن SSPR ناقص است.

چرا کاربر بعد از SSPR باز هم نمی‌تواند به لپ‌تاپ لاگین کند؟

معمولاً دو دلیل دارد: (۱) Password Writeback فعال یا سالم نیست، پس رمز جدید فقط در ابر معتبر است. (۲) کاربر دورکار است و لپ‌تاپ Hybrid-joined او cached credentials را دارد؛ نیاز به VPN یا Web sign-in دارد تا کش تازه شود.

استقرار SSPR در سازمان با ۵۰۰ کاربر چقدر طول می‌کشد؟

در تجربه‌ی من، فاز فنی (لایسنس، سیاست، writeback، تست) در ۳ تا ۵ روز کاری تمام می‌شود. اما فاز فرهنگی (کمپین ثبت‌نام کاربران و رساندن نرخ ثبت به بالای ۹۰٪) معمولاً ۳ تا ۶ هفته می‌برد و مهم‌ترین ریسک زمان‌بندی است.

آیا SSPR با MFA تداخل دارد؟

خیر، بلکه مکمل هم هستند. با Combined Registration کاربر یک بار روش‌ها را ثبت می‌کند و همان روش‌ها برای MFA و SSPR کار می‌کنند. توصیه می‌شود سیاست Conditional Access شما MFA را برای بازنشانی رمز الزامی کند تا امنیت خود SSPR بالا برود.