راهنمای جامع عیب‌یابی Conditional Access در Microsoft Entra برای تکنسین‌های هلپ دسک (۲۰۲۶)

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

عیب‌یابی Conditional Access در Microsoft Entra یعنی شناسایی سریع سیاست (Policy) مسدودکنندهٔ ورود، فهم دلیل شکست ارزیابی، و اعمال اصلاح دقیق بدون تضعیف وضعیت امنیتی مستأجر (Tenant). سه ابزار اصلی که هر تکنسین هلپ دسک باید در ۲۰۲۶ به آن‌ها مسلط باشد عبارت‌اند از: Sign-in Logs برای رصد رخداد واقعی، ابزار What If برای شبیه‌سازی سناریو، و کارپوشهٔ Insights & Reporting برای اندازه‌گیری اثر سیاست‌ها در طول زمان. در این راهنما، من گام‌به‌گام یک رانبوک عملی می‌دهم که مستقیماً از تیکت باز کنسول Entra تا رفع مشکل و تأیید نهایی پیش می‌رود.

• خطای AADSTS53003 به معنای بلاک شدن توسط یک Grant Control با کنترل «Block» یا یک شرط برآورده‌نشده مثل Device Compliance، Location یا Authentication Strength است.
• اولین گام همیشه بازکردن رخداد ورود کاربر در Sign-in Logs و مراجعه به تب Conditional Access برای مشاهدهٔ Policyهای Failure یا Not Applied است.
• ابزار What If فقط سیاست‌های Enabled یا Report-only را ارزیابی می‌کند و به وابستگی‌های سرویس (Service Dependency) توجه نمی‌کند؛ این محدودیت را در تحلیل خود بگنجانید.
• پیش از فعال‌سازی هر سیاست جدید در Production، ابتدا آن را در حالت Report-only اجرا کنید و از Insights Workbook برای تخمین Blast Radius استفاده کنید.
• حساب‌های Break-Glass (اضطراری) باید از تمام سیاست‌های Conditional Access مستثنی باشند تا از Lockout مستأجر جلوگیری شود.
• Named Locations، Compliance Sync، Authentication Methods و Terms of Use چهار ستون اصلی خطایابی روزمرهٔ CA هستند.

Conditional Access چگونه در Microsoft Entra کار می‌کند؟

Conditional Access یا CA، لایهٔ تصمیم‌گیری Microsoft Entra ID (نام قبلی: Azure Active Directory) است که بلافاصله پس از احراز هویت اولیه، ورود کاربر یا Workload Identity را در برابر مجموعه‌ای از سیاست‌ها ارزیابی می‌کند. هر سیاست از سه بخش تشکیل می‌شود: Assignments (کاربران، برنامه‌ها و شرایط)، Access Controls (Grant یا Session Controls)، و Report/Enable Mode. اگر همهٔ شرایط برقرار باشند، سیاست «Applied» می‌شود و کنترل‌های اعطا (مثلاً MFA یا Compliant Device) اجرا می‌گردد.

در ۲۰۲۶ نکتهٔ مهم این است که Microsoft چند تغییر رفتاری در CA اعمال کرده است: پشتیبانی از Authentication Strength به جای MFA سادهٔ قدیمی، ادغام کامل با Workload Identities، و گسترش قابلیت Continuous Access Evaluation (CAE) که به سیاست‌ها اجازه می‌دهد پس از تغییر وضعیت کاربر (مثلاً خروج از IP معتبر) بدون انتظار تا انقضای توکن، دسترسی را قطع کنند. تجربهٔ من می‌گوید بسیاری از تیکت‌های «چرا ناگهان قطع شدم؟» به فعال بودن CAE برمی‌گردد، نه به Policy جدید.

هر ورود یا Success می‌شود، یا Failure، یا Not Applied. تفاوت این سه در Sign-in Logs بسیار مهم است. «Not Applied» یعنی شرایط سیاست برقرار نبوده و اصلاً ارزیابی نشده؛ در حالی که «Failure» یعنی سیاست شامل شد اما کنترل اعطا برآورده نشد. اگر این تفاوت را نفهمید، ساعت‌ها دنبال سیاستی می‌گردید که اصلاً درگیر نبوده است.

چگونه بفهمم کدام سیاست Conditional Access کاربر را بلاک کرده است؟

سریع‌ترین راه رفتن به مسیر زیر است: Microsoft Entra admin center → Identity → Monitoring & health → Sign-in logs. برای ورود کافی است حداقل نقش Reports Reader داشته باشید. فیلترها را روی نام کاربر، بازهٔ زمانی و «Status: Failure» تنظیم کنید. رخداد را باز کنید و به تب Conditional Access بروید. اینجا لیست تمام سیاست‌های ارزیابی‌شده به‌همراه وضعیت هرکدام (Success / Failure / Not Applied / Report-only) دیده می‌شود.

برای رخدادهای پیچیده‌تر، Correlation ID را از تب Basic Info کپی کنید و در Log Analytics کوئری KQL بزنید:

SigninLogs
| where TimeGenerated > ago(1h)
| where CorrelationId == "<paste-correlation-id-here>"
| mv-expand policy = ConditionalAccessPolicies
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          IPAddress,
          Location = tostring(LocationDetails.city),
          PolicyName        = tostring(policy.displayName),
          PolicyResult      = tostring(policy.result),
          GrantControls     = tostring(policy.enforcedGrantControls),
          SessionControls   = tostring(policy.enforcedSessionControls),
          FailureReason     = ResultDescription
| where PolicyResult in ("failure", "reportOnlyFailure")
| sort by TimeGenerated desc

خروجی مورد انتظار: یک یا چند ردیف با PolicyResult = "failure". اگر GrantControls شامل Block باشد، سیاست به‌صراحت ورود را رد کرده است. اگر شامل Mfa, CompliantDevice یا AuthenticationStrength باشد، کاربر نتوانسته یکی از این کنترل‌ها را برآورده کند. تب Troubleshooting and support در همان رخداد نیز معمولاً پیام واضحی مثل «Device is not marked as compliant» می‌دهد که مسیر تیکت را کوتاه می‌کند.

در تجربهٔ من، ۷۰٪ تیکت‌ها با همین ۳ کلیک (سرچ کاربر، فیلتر Failure، تب Conditional Access) حل می‌شوند. اگر پیش از این راهنمای عیب‌یابی Outlook در Microsoft 365 را مطالعه کرده‌اید، همان جریان تحلیل رخداد اینجا هم صادق است.

شایع‌ترین کدهای خطای AADSTS در Conditional Access و راه‌حل‌ها

Microsoft Entra خطاهای CA را با پیشوند AADSTS برمی‌گرداند. دانستن معنی هر کد سرعت تشخیص را چند برابر می‌کند. جدول زیر پرتکرارترین‌ها را با یک اقدام اول‌گام خلاصه می‌کند:

کد خطا	معنی	عامل رایج	اقدام اول‌گام
AADSTS53003	Token issuance blocked by CA	Grant Control با «Block» یا شرط برآورده‌نشده	باز کردن Sign-in log و بررسی Grant Controls اعمالی
AADSTS53000	Device is not compliant	دستگاه Non-compliant یا خارج از Intune	راستی‌آزمایی وضعیت Compliance در Intune
AADSTS53001	Device is not Hybrid/Entra joined	عدم Join دستگاه	بررسی dsregcmd /status در دستگاه کاربر
AADSTS53002	Approved client app required	استفاده از اپ غیرمجاز مثل Mail.app	راهنمایی کاربر به Outlook Mobile یا Edge Work
AADSTS50158	External security challenge not satisfied	MFA خارجی مثل Duo پاسخ نداده	بررسی وضعیت Custom Controls / Duo Connector
AADSTS500011	Resource principal not found in tenant	Endpoint اشتباه (common) به‌جای Tenant ID	جایگزینی /common با Tenant ID دقیق

خطای AADSTS53003 پرچالش‌ترین کد است، چون به تنهایی مشخص نمی‌کند دقیقاً کدام کنترل شکست خورده. راز اصلی این است: پیام کاربر را رها کنید و مستقیم به Sign-in log بروید. تقریباً همیشه در تب Conditional Access یک سیاست با نتیجهٔ Failure و یک Grant Control مشخص می‌بینید. آنجا داستان واقعی روایت می‌شود.

ابزار What If در Conditional Access چیست و چگونه از آن استفاده کنیم؟

ابزار What If شبیه‌ساز رسمی Microsoft برای CA است. مسیر: Entra admin center → Protection → Conditional Access → Policies → What If. با تعیین کاربر (یا Workload Identity)، برنامهٔ هدف، Platform، Location، Client App و Sign-in Risk، ابزار به شما می‌گوید کدام سیاست‌ها به این ورود اعمال می‌شوند و چه کنترل‌هایی درخواست می‌کنند، بدون آنکه واقعاً کاربر را وادار به لاگین کنید.

نکتهٔ مهم: What If فقط سیاست‌های Enabled و Report-only را ارزیابی می‌کند. سیاست‌های Disabled نادیده گرفته می‌شوند. علاوه بر آن، ابزار وابستگی‌های سرویس را در نظر نمی‌گیرد؛ یعنی اگر برای Teams شبیه‌سازی می‌کنید، سیاست‌های تنظیم‌شده روی Exchange Online (که Teams به آن وابسته است) در نتایج ظاهر نمی‌شوند. این محدودیت را همیشه در ذهن داشته باشید و برای سناریوهای Cross-service چند بار جداگانه اجرا کنید.

گردش کار من این است: قبل از هر تغییر روی Policy در Production، دقیقاً همان سناریوی کاربری که مشکل داشته را در What If شبیه‌سازی می‌کنم. اگر خروجی، همان Failure واقعی را بازتولید نکرد، یعنی مشکل خارج از دامنهٔ What If است (احتمالاً وابستگی سرویس یا CAE). اگر بازتولید شد، اصلاح سیاست را اعمال می‌کنم و دوباره What If می‌زنم؛ باید سبز شود. سپس اجازه می‌دهم کاربر تست کند. این چرخهٔ سه‌مرحله‌ای (بازتولید، اصلاح، تأیید) از تصمیمات هیجانی جلوگیری می‌کند.

برای اسکریپت‌نویسان، همین منطق از طریق What If API در Microsoft Graph در دسترس است و می‌توانید ارزیابی گروهی برای صدها کاربر انجام دهید (مخصوصاً موقع تست تغییرات کلان روی مستأجر بزرگ). اگر تعداد Failureها بیش از حد آستانه بود، تغییر را روی Production نبرید.

تست سیاست‌ها بدون تأثیر بر کاربران با حالت Report-only

حالت Report-only مثل «حالت آزمایشی» است: سیاست ارزیابی می‌شود و نتیجه در Sign-in log ثبت می‌گردد، اما هیچ Grant Control واقعاً اعمال نمی‌شود. کاربر متوجه چیزی نمی‌شود، اما شما داده‌های واقعی از تأثیر سیاست جمع می‌کنید. این تنها راه امن برای معرفی یک سیاست جدید MFA یا Compliant Device در یک محیط بزرگ است.

گردش کار پیشنهادی: سیاست را در حالت Report-only فعال کنید. ۷ تا ۱۴ روز صبر کنید. Insights & Reporting Workbook را باز کنید و تعداد Report-only Failureها را ببینید. هر Failure یعنی یک کاربر که در حالت Enabled واقعی بلاک می‌شد. اگر تعداد قابل‌قبول است و کاربران Failure منطقاً باید مسدود می‌شدند، سیاست را روی Enabled بگذارید. اگر عددی غیرمنتظره است، دوباره ابتدا کاربران گروه Exclude را تنظیم کنید.

هرگز سیاست جدید را مستقیم از Disabled به Enabled نبرید. حتی برای تغییرات کوچک، ۴۸ ساعت Report-only بگذارید. یک بار سیاست ساده‌ای اضافه کردم برای بلاک Legacy Auth؛ گمان می‌کردم تأثیر صفر است. Report-only نشان داد پنج اسکریپت اتوماسیون هنوز از Basic Auth استفاده می‌کنند. اگر مستقیم Enable می‌کردم، اپراتور شب زنگ می‌زد.

عیب‌یابی مسائل Device Compliance و Intune Join

پرتکرارترین علت خطای AADSTS53000 و AADSTS53001 مربوط به Compliance و Join Status است. برای تشخیص سریع، از کاربر بخواهید در Command Prompt دستور زیر را اجرا کند:

dsregcmd /status

خروجی مهم را در بخش «Device State» بخوانید:

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+
             AzureAdJoined : YES
          EnterpriseJoined : NO
              DomainJoined : NO
                DeviceName : LAPTOP-1234
+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+
              AzureAdPrt : YES
    AzureAdPrtUpdateTime : 2026-06-30 09:42:11.000 UTC
     AzureAdPrtExpiryTime: 2026-07-14 09:42:11.000 UTC

اگر AzureAdJoined = NO است، دستگاه از Entra خارج شده و باید دوباره Join شود. اگر AzureAdPrt = NO، توکن PRT خراب شده و کاربر باید یک بار خروج/ورود کند. برای بررسی Compliance در Intune مسیر: Intune admin center → Devices → All devices → [Device] → Device compliance. اگر ستون «Compliance state» چیزی جز Compliant نشان می‌دهد، روی نام Policy کلیک کنید تا Setting دقیق مسبب شکست را ببینید — معمولاً BitLocker غیرفعال، Antivirus قدیمی، یا نسخهٔ OS پایین‌تر از حد مجاز است.

برای Sync سریع پس از اصلاح، در Company Portal روی Sync یا از خط فرمان:

# اجرا در PowerShell به‌عنوان کاربر
Get-ScheduledTask -TaskName "PushLaunch" | Start-ScheduledTask

پیشنهاد می‌کنم راهنمای جامع مدیریت Microsoft 365 را برای زمینهٔ گسترده‌تر Intune و Compliance مرور کنید.

Named Locations و رفع مسائل مبتنی‌بر IP و مکان

سیاست‌هایی که با «Trusted locations» یا «Countries» شرط دارند، پس از تغییر ISP یا سفر کاربر خیلی زود شکسته می‌شوند. لیست Named Locations در مسیر Entra admin center → Protection → Conditional Access → Named locations در دسترس است. هر رکورد یا مبتنی بر IP Range (v4/v6) است یا مبتنی بر کشور بر اساس Geo-IP.

وقتی کاربر می‌گوید «از خانه کار نمی‌کند اما در دفتر بی‌مشکل است»، تقریباً همیشه یک Named Location یا یک Policy با «Locations = Trusted» علت است. IP خانگی کاربر را از سرویس whatismyip.com بگیرید و در لیست IP Rangeها جست‌وجو کنید. اگر پیدا نشد و انتظار داشتید باشد (مثلاً VPN)، یا VPN وصل نبوده یا Egress IP جدید افزوده نشده است.

برای Automation Accountها و Azure Functionها، Egress IP معمولاً پویا است. راه‌حل ما این است: VNET Integration + NAT Gateway تا IP خروجی ثابت شود، سپس افزودن آن IP به Named Locations trusted. برای مستأجرهای کوچک‌تر، استفاده از Managed Identity + Workload Identity Conditional Access جدید ۲۰۲۶ گاهی سریع‌تر است.

بازیابی از Lockout و پیکربندی حساب Break-Glass

بدترین سناریو این است که یک ادمین سیاستی بگذارد که همهٔ ادمین‌ها را بلاک کند. Microsoft مکانیزم رسمی برای این حالت دارد: حساب‌های Emergency Access یا Break-Glass. حداقل دو حساب Cloud-only با نقش Global Administrator بسازید، رمز طولانی و ذخیره‌شده در Safe فیزیکی، و از تمام سیاست‌های CA Exclude کنید (چه Block و چه MFA).

اگر بدون Break-Glass گیر افتاده‌اید و هیچ ادمینی نمی‌تواند سیاست را غیرفعال کند، تنها راه ثبت تیکت پشتیبانی Microsoft است. تیم پشتیبانی پس از تأیید هویت مالکیت مستأجر، سیاست مشکل‌دار را غیرفعال می‌کند. این فرآیند معمولاً ۴ تا ۲۴ ساعت طول می‌کشد. تجربهٔ من: بلافاصله پس از خواندن این پاراگراف، اگر Break-Glass ندارید، ساختن آن اولین کارتان امروز باشد.

برای مانیتور کردن استفادهٔ حساب‌های Break-Glass، در Sensitivity Alerts یا Log Analytics یک Alert بسازید که هربار یکی از این UPNها sign-in کند، فوراً تیم را مطلع کند. استفادهٔ عادی از این حساب‌ها یعنی خطر: یا شما را هک کرده‌اند یا یک ادمین دارد نقض procedure می‌کند.

Insights & Reporting Workbook برای تحلیل بلندمدت

کارپوشهٔ Insights & Reporting در Entra admin center → Protection → Conditional Access → Insights and reporting قرار دارد. برای فعال‌سازی نیاز به Log Analytics Workspace متصل و لایسنس Entra ID P1 دارید. این کارپوشه به شما اجازه می‌دهد اثر یک سیاست خاص را در طول زمان ببینید: چند Sign-in به آن اعمال شد، چند تا موفق بودند، چند تا Report-only Failure زدند و روند کلی چگونه است.

موقع Onboarding سیاست جدید، دو نمودار را زیر نظر می‌گیرم: «Failures over time» و «Users impacted». اگر منحنی Failures ناگهان جهش پیدا کند، احتمالاً یک تغییر Upstream (مثلاً Password Reset، تغییر گروه، خرابی Sync) رخ داده. کارپوشه به شما زبان مشترک با تیم امنیت می‌دهد تا تصمیم‌ها را با داده بگیرید، نه با احساس.

یک قابلیت جدید که در ۲۰۲۶ اضافه شد، «Policy diff» است: هربار یک ادمین سیاست را ویرایش کند، snapshot ذخیره می‌شود و می‌توانید ببینید دقیقاً چه چیزی تغییر کرده و چه کسی آن را انجام داده. این ویژگی برای Post-mortem رخدادها طلا است. اگر پیش‌تر راهنمای مهاجرت از Basic Auth به OAuth 2.0 را خوانده باشید، متوجه می‌شوید Insights چقدر در تشخیص لاگین‌های Legacy باقیمانده مفید است.

رانبوک ۹‌مرحله‌ای هلپ دسک برای تیکت‌های CA

این چک‌لیست دقیقاً همان چیزی است که تیم من هنگام هر تیکت CA اجرا می‌کند. اگر مرحله‌به‌مرحله دنبال کنید، میانگین زمان حل تیکت شما زیر ۱۵ دقیقه خواهد رفت:

1. جمع‌آوری اطلاعات پایه: UPN کاربر، Application، Timestamp دقیق (با Timezone)، پیام خطای دیده‌شده، Screenshot.
2. باز کردن Sign-in log: Entra admin center → Sign-in logs، فیلتر UserName + بازهٔ ±۱۵ دقیقه.
3. Correlation ID: از تب Basic Info کپی کنید — این ID زبان مشترک بین شما، امنیت و Microsoft است.
4. تب Conditional Access: کدام Policy با نتیجهٔ Failure است؟ چه Grant Control خواسته شده؟
5. تب Troubleshooting and support: پیام خلاصه را بخوانید؛ اغلب همان‌جا راه‌حل هست.
6. شبیه‌سازی What If: اگر تنظیمات مشکوک است، همان سناریو را در What If بازتولید کنید.
7. اقدام اصلاحی: بسته به نوع خطا — Compliance Sync، اضافه‌کردن IP به Named Location، ثبت MFA جدید، یا استثنای کاربر برای مدت محدود.
8. تأیید: از کاربر بخواهید دوباره لاگین کند. Sign-in log جدید باید Success نشان دهد و Policyهای CA همه Success یا Not Applied باشند.
9. مستندسازی: در تیکت یا Wiki سازمان بنویسید چه چیزی مشکل ایجاد کرد و چه‌طور حل شد. این کار برای تیکت بعدی مشابه، عمر تشخیص را ثانیه‌ای می‌کند.

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

چگونه سیاست Conditional Access بلاک‌کننده را در ۱ دقیقه پیدا کنم؟

Sign-in log کاربر را باز کنید، به تب Conditional Access بروید و دنبال سیاستی با نتیجهٔ Failure و Grant Control از نوع Block یا CompliantDevice/Mfa بگردید. این سریع‌ترین راه است و در ۹۰٪ موارد پاسخ در همان یک صفحه دیده می‌شود.

آیا می‌توانم Conditional Access را برای یک کاربر خاص موقتاً غیرفعال کنم؟

نه به‌طور کامل، اما می‌توانید کاربر را در بخش Assignments → Users → Exclude آن سیاست خاص قرار دهید. این بهترین راه برای استثنای موقت است. یادداشت بگذارید و پس از رفع مشکل حتماً کاربر را از Exclude خارج کنید.

ابزار What If چقدر دقیق است؟

What If در محدودهٔ سیاست‌های Enabled و Report-only بسیار دقیق است، اما وابستگی‌های سرویس (مثلاً وابستگی Teams به Exchange Online) را ارزیابی نمی‌کند. برای سناریوهای Cross-service، هر برنامهٔ وابسته را جداگانه شبیه‌سازی کنید.

اگر همهٔ ادمین‌ها بلاک شدند چه کنم؟

ابتدا با حساب Break-Glass وارد شوید (اگر ساخته‌اید). اگر ندارید، سریعاً تیکت شدت-A به Microsoft Support ثبت کنید. تیم پشتیبانی پس از اثبات مالکیت مستأجر سیاست مشکل‌دار را برایتان غیرفعال می‌کند. بعد از این تجربه، اولین کارتان ساختن دو حساب Break-Glass باشد.

تفاوت Failure و Not Applied در گزارش CA چیست؟

Not Applied یعنی شرایط سیاست (کاربر، برنامه، پلتفرم) با ورود کاربر منطبق نبوده و اصلاً ارزیابی نشده. Failure یعنی سیاست شامل شد ولی کنترل اعطا برآورده نشد. اگر دنبال یک بلاک هستید، تنها روی Failureها تمرکز کنید، نه Not Appliedها.

آیا Conditional Access روی کاربران Guest هم اعمال می‌شود؟

بله، اما رفتار پیش‌فرض متفاوت است. Guestها در اکثر سیاست‌ها به‌صورت پیش‌فرض شامل نمی‌شوند مگر آنکه در Assignments صریحاً «All users» یا «All guest and external users» انتخاب شده باشد. برای اعمال کنترل روی Guestها از قابلیت Cross-tenant Access Settings و External Identities Policies استفاده کنید.

برای اطلاعات فنی به‌روز، مراجع رسمی زیر بهترین منابع هستند: مستند رسمی Microsoft برای عیب‌یابی Conditional Access، راهنمای ابزار What If در Microsoft Learn، و مستند رسمی Insights and Reporting Workbook.