مقدمه: چرا Basic Authentication داره حذف میشه؟
اگه مقالات قبلی ما درباره مدیریت و عیبیابی Microsoft 365 و عیبیابی Outlook رو خوندید، احتمالاً با اکوسیستم Exchange Online آشنایید. ولی بذارید یه خبر مهم رو صاف و پوستکنده بگم: مایکروسافت داره Basic Authentication رو برای SMTP AUTH در Exchange Online برای همیشه حذف میکنه — و این تغییر مستقیماً روی کار روزمره تیم هلپ دسک شما تأثیر میذاره.
Basic Authentication یه پروتکل قدیمیه که نام کاربری و رمز عبور رو بهصورت متن ساده ارسال میکنه. صادقانه بگم، اینکه هنوز جاهایی ازش استفاده میشه یکم تعجبآوره — چون آسیبپذیری شدید در برابر حملات Credential Theft، Brute Force و Man-in-the-Middle داره.
مایکروسافت بهعنوان بخشی از Secure Future Initiative تصمیم گرفته این پروتکل رو با OAuth 2.0 جایگزین کنه. خب، بریم ببینیم عملاً چیکار باید بکنیم.
این مقاله یه راهنمای عملی و قدمبهقدم برای تکنسینهای هلپ دسکه — از شناسایی سیستمهای آسیبپذیر گرفته تا پیادهسازی OAuth 2.0 و مدیریت دستگاههای قدیمی مثل پرینترها و اسکنرها.
جدول زمانی حذف Basic Auth (بهروزرسانی ۲۰۲۶)
مایکروسافت در ۲۷ ژانویه ۲۰۲۶ جدول زمانی جدیدی منتشر کرد. خبر خوب اینه که نسبت به برنامه اولیه، زمان بیشتری به سازمانها داده شده:
| تاریخ | تغییر |
|---|---|
| حالا تا دسامبر ۲۰۲۶ | رفتار SMTP AUTH Basic Auth بدون تغییر باقی میمونه |
| پایان دسامبر ۲۰۲۶ | Basic Auth بهصورت پیشفرض غیرفعال میشه (ادمینها هنوز میتونن فعالش کنن) |
| تننتهای جدید بعد از دسامبر ۲۰۲۶ | Basic Auth اصلاً در دسترس نیست |
| نیمه دوم ۲۰۲۷ | حذف کامل — تمام اتصالات Basic Auth با خطا رد میشن |
⚠️ نکته مهم: تاریخ قبلی آوریل ۲۰۲۶ لغو شده. ولی اشتباه نکنید — فرصت نامحدود نیست و شروع مهاجرت همین الان ضروریه.
چه سیستمهایی تحت تأثیر قرار میگیرن؟
بهعنوان تکنسین هلپ دسک، اولین قدم اینه که بدونید این تغییر روی چه دستگاهها و اپلیکیشنهایی تأثیر میذاره. لیست زیر رو خوب نگاه کنید:
- پرینترها و اسکنرهای چندکاره (MFP): بیشتر دستگاههای Scan-to-Email از Basic Auth استفاده میکنن (و معمولاً اونایی هستن که آخر از همه یادتون میافته)
- اپلیکیشنهای LOB (Line of Business): نرمافزارهای ERP، CRM و سیستمهای مانیتورینگ که ایمیل ارسال میکنن
- اسکریپتهای PowerShell: اسکریپتهایی که با
Send-MailMessageایمیل میفرستن - سرورهای On-Premises: اپلیکیشنهایی که مستقیماً به smtp.office365.com وصل میشن
- App Passwords: رمزهای اپلیکیشن که وابسته به Basic Auth هستن و بعد از حذف دیگه کار نمیکنن
قدم ۱: شناسایی و فهرستبرداری از سیستمهای آسیبپذیر
خب، بریم سراغ بخش عملی. اول از همه باید بدونید چه سیستمهایی توی سازمان از Basic Auth استفاده میکنن. از تجربه بگم، تعداد این سیستمها معمولاً بیشتر از چیزیه که فکر میکنید!
استفاده از SMTP AUTH Client Submission Report
وارد Exchange Admin Center بشید و به بخش Mail Flow → Message Trace برید. البته راه سریعترش PowerShell هست:
# اتصال به Exchange Online
Install-Module -Name ExchangeOnlineManagement -Force
Connect-ExchangeOnline -UserPrincipalName [email protected]
# بررسی وضعیت SMTP AUTH در سطح سازمان
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
# بررسی میلباکسهایی که SMTP AUTH فعال دارن
Get-CASMailbox -ResultSize Unlimited | Where-Object {
$_.SmtpClientAuthenticationDisabled -eq $false
} | Select-Object DisplayName, PrimarySmtpAddress, SmtpClientAuthenticationDisabled
بررسی Sign-in Logs در Microsoft Entra
برای شناسایی دقیقتر، لاگهای ورود رو هم بررسی کنید. این روش خیلی کمک میکنه:
- وارد Microsoft Entra Admin Center بشید
- به Monitoring & health → Sign-in logs برید
- فیلتر Client App رو روی Authenticated SMTP بذارید
- لیست تمام اکانتهایی که با Basic Auth از SMTP استفاده میکنن ظاهر میشه
قدم ۲: دستهبندی سیستمها
بعد از شناسایی، وقتشه که سیستمها رو دستهبندی کنید. این مرحله خیلی مهمه چون مسیر مهاجرت هر دسته فرق میکنه:
| دسته | توضیح | اقدام |
|---|---|---|
| قابل ارتقا به OAuth | اپلیکیشنها و دستگاههایی که از OAuth 2.0 پشتیبانی میکنن | مهاجرت مستقیم به OAuth |
| قابل استفاده از SMTP Relay | دستگاههای قدیمی بدون پشتیبانی OAuth | استفاده از SMTP Relay یا Direct Send |
| نیاز به جایگزینی | سیستمهای منسوخ بدون آپدیت | برنامهریزی برای جایگزینی سختافزار/نرمافزار |
قدم ۳: پیادهسازی OAuth 2.0 برای SMTP AUTH
اینجا مهمترین بخش مهاجرته. بیایید قدمبهقدم پیش بریم — و نگران نباشید، سعی کردم همه چیز رو ساده و قابل فهم توضیح بدم.
۳.۱ — ثبت اپلیکیشن در Microsoft Entra
- وارد Azure Portal (
portal.azure.com) بشید - به Microsoft Entra ID → App registrations → New registration برید
- یه اسم مناسب انتخاب کنید (مثلاً
SMTP-OAuth-App) - نوع اکانت رو Accounts in this organizational directory only بذارید
- روی Register کلیک کنید
- Application (client) ID و Directory (tenant) ID رو یادداشت کنید — بعداً بهشون نیاز دارید
۳.۲ — ایجاد Client Secret
- در صفحه اپلیکیشن، به Certificates & secrets برید
- روی New client secret کلیک کنید
- یه توضیح وارد کنید و مدت اعتبار رو انتخاب کنید
- Value رو فوراً کپی و ذخیره کنید (جدی میگم، فقط یک بار نمایش داده میشه و اگه از دست بدیدش باید یه secret جدید بسازید)
۳.۳ — تنظیم API Permissions
- به API permissions → Add a permission برید
- تب APIs my organization uses رو انتخاب کنید
- عبارت Office 365 Exchange Online رو جستجو کنید
- نوع Application permissions رو انتخاب کنید
- دسترسی SMTP.SendAsApp رو تیک بزنید
- روی Grant admin consent کلیک کنید
۳.۴ — ثبت Service Principal در Exchange Online
⚠️ این مرحله رو خیلیها فراموش میکنن! و بعد ساعتها وقت تلف میکنن تا بفهمن چرا خطای "Client not authenticated" میگیرن. پس حتماً این قدم رو انجام بدید:
# اتصال به Exchange Online PowerShell
Connect-ExchangeOnline -UserPrincipalName [email protected]
# دریافت Object ID از Enterprise Applications (نه App Registration!)
# در Azure Portal: Enterprise Applications → اپلیکیشن شما → Overview → Object ID
# ثبت Service Principal
New-ServicePrincipal -AppId "<APPLICATION_ID>" -ServiceId "<ENTERPRISE_APP_OBJECT_ID>"
# مهم: Object ID باید از صفحه Enterprise Applications باشه، نه App Registrations!
یه نکته که خیلی مهمه: Object ID توی صفحه Enterprise Applications با Object ID توی App Registrations فرق میکنه. باید حتماً از Enterprise Applications بگیریدش.
۳.۵ — اختصاص دسترسی به میلباکس
# اختصاص دسترسی ارسال ایمیل از میلباکس خاص
Add-MailboxPermission -Identity "[email protected]" `
-User <ENTERPRISE_APP_OBJECT_ID> `
-AccessRights FullAccess `
-InheritanceType All
۳.۶ — فعالسازی SMTP AUTH روی میلباکس
# فعالسازی SMTP AUTH برای میلباکس مورد نظر
Set-CASMailbox -Identity "[email protected]" -SmtpClientAuthenticationDisabled $false
۳.۷ — دریافت Access Token و ارسال ایمیل
حالا وقتشه که Access Token بگیرید و از طریق XOAUTH2 ایمیل ارسال کنید:
# دریافت Access Token
$tokenUrl = "https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token"
$body = @{
client_id = "<APPLICATION_ID>"
client_secret = "<CLIENT_SECRET>"
scope = "https://outlook.office365.com/.default"
grant_type = "client_credentials"
}
$tokenResponse = Invoke-RestMethod -Uri $tokenUrl -Method POST -Body $body
$accessToken = $tokenResponse.access_token
# ارسال ایمیل با استفاده از .NET و XOAUTH2
$smtpServer = "smtp.office365.com"
$smtpPort = 587
$from = "[email protected]"
$to = "[email protected]"
$subject = "Test OAuth SMTP"
$bodyText = "This is a test email sent via OAuth 2.0"
# ساخت SASL XOAUTH2 token
$authString = "user=$from$([char]1)auth=Bearer $accessToken$([char]1)$([char]1)"
$authBytes = [System.Text.Encoding]::UTF8.GetBytes($authString)
$authBase64 = [System.Convert]::ToBase64String($authBytes)
# اتصال و ارسال
$tcpClient = New-Object System.Net.Sockets.TcpClient($smtpServer, $smtpPort)
$stream = $tcpClient.GetStream()
$sslStream = New-Object System.Net.Security.SslStream($stream)
# ... ادامه handshake و ارسال SMTP commands
💡 نکته عملی: برای محیط پروداکشن، پیشنهاد میکنم از کتابخانههای آماده مثل MailKit (برای .NET) یا msal-python (برای Python) استفاده کنید. این کتابخانهها XOAUTH2 رو خودکار مدیریت میکنن و کلی درد سر کمتر دارید.
قدم ۴: راهحل برای پرینترها و اسکنرهای قدیمی
این بخش احتمالاً بیشترین تیکت هلپ دسک رو تولید میکنه. پرینترها و اسکنرهای چندکاره (MFP) معمولاً آخرین دستگاههایی هستن که آپدیت میشن — و اولینهایی هستن که بعد از تغییرات خراب میشن!
گزینه ۱: آپدیت Firmware
قبل از هر کاری، ببینید آیا تولیدکننده دستگاه فریمور جدید با پشتیبانی OAuth ارائه داده یا نه:
- Xerox: فریمور جدید برای بسیاری از مدلها OAuth 2.0 رو پشتیبانی میکنه
- HP: مدلهای جدیدتر با آپدیت فریمور قابلیت OAuth دارن
- Canon: داکیومنت رسمی برای پیکربندی OAuth با Microsoft 365 منتشر شده
حتماً مدل دقیق دستگاه و نسخه فریمور فعلی رو قبل از شروع بررسی کنید.
گزینه ۲: SMTP Relay
اگه دستگاه از OAuth پشتیبانی نمیکنه (که اکثراً نمیکنن)، بهترین راهحل SMTP Relay هست. این روش نیازی به احراز هویت کاربر نداره و فقط بر اساس IP آدرس کار میکنه:
# تنظیم Connector در Exchange Online برای SMTP Relay
# Exchange Admin Center → Mail Flow → Connectors → New Connector
# تنظیمات Connector:
# From: Your organization email server
# To: Office 365
# Authentication: By verifying the IP address of the sending server
# IP Address: آدرس IP ثابت سرور یا دستگاه شما
مزایای این روش:
- نیازی به احراز هویت کاربر نیست
- فقط نیاز به IP ثابت داره
- با هر دستگاه و اپلیکیشنی کار میکنه
- محدودیت: ایمیلها فقط به آدرسهای داخل سازمان ارسال میشن
گزینه ۳: Direct Send
برای ارسال ایمیل بدون احراز هویت به آدرسهای داخلی سازمان:
# تنظیمات Direct Send:
# SMTP Server: yourdomain-com.mail.protection.outlook.com
# Port: 25
# TLS: Required
# Authentication: None
# Sender: باید آدرس معتبر از دامنه شما باشه
گزینه ۴: SMTP Relay Bridge (سرویس واسط)
اگه نیاز به ارسال ایمیل به آدرسهای خارج سازمان هم دارید و دستگاه OAuth رو پشتیبانی نمیکنه، میتونید یه سرور SMTP واسط راهاندازی کنید. بهنظرم این راهحل برای سازمانهای بزرگتر خیلی خوب جواب میده:
- دستگاهها با Basic Auth یا بدون احراز هویت به سرور واسط وصل میشن
- سرور واسط با OAuth 2.0 به Exchange Online متصل میشه
- ابزارهایی مثل hMailServer یا IIS SMTP روی Windows Server قابل استفاده هستن
قدم ۵: تست و اعتبارسنجی
قبل از غیرفعال کردن Basic Auth در سطح سازمان، حتماً — و تأکید میکنم حتماً — همه چیز رو تست کنید. هیچچیز بدتر از این نیست که صبح دوشنبه بیاید سر کار و ببینید هیچ سیستمی ایمیل نمیفرسته.
چکلیست تست
- ✅ اپلیکیشنهای OAuth: ارسال و دریافت ایمیل بدون مشکل
- ✅ پرینترها/اسکنرها: Scan-to-Email با روش جدید کار میکنه
- ✅ اسکریپتهای اتوماسیون: Token Refresh بدون خطا انجام میشه
- ✅ مانیتورینگ: Alert ایمیلها بهدرستی ارسال میشن
- ✅ Conditional Access: پالیسیها با OAuth سازگارن
تست با PowerShell
# تست سریع ارسال ایمیل با OAuth Token
# اگه token معتبر دارید:
$smtpClient = New-Object System.Net.Mail.SmtpClient("smtp.office365.com", 587)
$smtpClient.EnableSsl = $true
# برای تست اولیه با Telnet:
# telnet smtp.office365.com 587
# EHLO yourdomain.com
# STARTTLS
# AUTH XOAUTH2 <base64_token>
قدم ۶: غیرفعالسازی Global و مدیریت استثناها
وقتی مطمئن شدید همه چیز درست کار میکنه، وقتشه Basic Auth رو در سطح سازمان غیرفعال کنید:
# غیرفعالسازی SMTP AUTH در سطح سازمان
Set-TransportConfig -SmtpClientAuthenticationDisabled $true
# بررسی وضعیت
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
# اگه هنوز بعضی میلباکسها نیاز به Basic Auth دارن (موقت):
Set-CASMailbox -Identity "[email protected]" -SmtpClientAuthenticationDisabled $false
# لیست استثناها رو ترک کنید و مرتب کاهش بدید
Get-CASMailbox -ResultSize Unlimited | Where-Object {
$_.SmtpClientAuthenticationDisabled -eq $false
} | Select-Object DisplayName, PrimarySmtpAddress
نکته مهم: لیست استثناها رو مرتب مرور کنید و سعی کنید هر ماه تعدادشون رو کمتر کنید. هدف نهایی صفر استثنا هست.
خطاهای رایج و نحوه رفع
این خطاها رو احتمالاً زیاد میبینید (مخصوصاً در هفتههای اول مهاجرت):
| خطا | علت | راهحل |
|---|---|---|
550 5.7.30 Basic authentication is not supported | Basic Auth غیرفعال شده | مهاجرت به OAuth یا SMTP Relay |
535 5.7.139 Authentication unsuccessful | Token نامعتبر یا منقضی | بررسی Client ID/Secret و دریافت token جدید |
Client not authenticated to send mail | Service Principal ثبت نشده | اجرای New-ServicePrincipal با Object ID صحیح از Enterprise Applications |
SmtpClientAuthentication is disabled | SMTP AUTH در میلباکس غیرفعاله | فعالسازی با Set-CASMailbox |
Token request failed | Scope اشتباه | Scope باید https://outlook.office365.com/.default باشه |
برنامه مهاجرت پیشنهادی برای تیم هلپ دسک
بر اساس تجربه، یه برنامه ۱۴ هفتهای واقعبینانهست. عجله نکنید ولی معطل هم نکنید:
| مرحله | زمان پیشنهادی | اقدامات |
|---|---|---|
| فاز ۱: شناسایی | هفته ۱-۲ | فهرستبرداری کامل، بررسی لاگها، شناسایی همه سیستمهای وابسته |
| فاز ۲: دستهبندی | هفته ۳ | تقسیم سیستمها به سه دسته (OAuth / Relay / جایگزینی) |
| فاز ۳: Pilot | هفته ۴-۶ | مهاجرت ۵-۱۰ سیستم اصلی، تست OAuth و Relay |
| فاز ۴: مهاجرت موجی | هفته ۷-۱۲ | مهاجرت دستهای بر اساس اولویت کسبوکار |
| فاز ۵: پاکسازی | هفته ۱۳-۱۴ | غیرفعالسازی Global، حذف استثناها، مستندسازی نهایی |
سؤالات متداول
آیا بعد از حذف Basic Auth، App Passwords هم کار نمیکنن؟
بله. App Passwords به Basic Authentication وابسته هستن. بعد از غیرفعال شدن Basic Auth برای SMTP، این رمزها هم از کار میافتن. باید به OAuth 2.0 مهاجرت کنید یا از روشهای جایگزین مثل SMTP Relay استفاده کنید.
پرینتر قدیمی ما OAuth پشتیبانی نمیکنه. چیکار کنیم؟
سه گزینه دارید: اول فریمور دستگاه رو آپدیت کنید و ببینید آیا نسخه جدید OAuth رو پشتیبانی میکنه. اگه نه، از SMTP Relay با IP ثابت استفاده کنید (برای ارسال داخلی). و اگه نیاز به ارسال خارجی هم دارید، یه سرور SMTP واسط راهاندازی کنید که از یه طرف Basic Auth قبول کنه و از طرف دیگه با OAuth به Exchange Online وصل شه.
تفاوت SMTP Relay و Direct Send چیه؟
SMTP Relay از یه Connector در Exchange Online استفاده میکنه و بر اساس IP آدرس احراز هویت میشه. Direct Send مستقیماً به MX record سازمان وصل میشه و نیازی به احراز هویت نداره. هر دو فقط برای ارسال به آدرسهای دامنه خودتون کار میکنن و نیازی به OAuth یا Basic Auth ندارن.
آیا میتونم از Microsoft Graph API بهجای SMTP AUTH استفاده کنم؟
بله، و صادقانه بگم مایکروسافت هم همین روش رو توصیه میکنه. Microsoft Graph API (POST /users/{id}/sendMail) از OAuth 2.0 استفاده میکنه و نیازی به فعال بودن SMTP AUTH روی میلباکس نداره. برای اپلیکیشنهای جدید، Graph API گزینه بهتری نسبت به SMTP AUTH با OAuth هست.
اگه مهاجرت نکنیم چه اتفاقی میافته؟
از پایان دسامبر ۲۰۲۶، Basic Auth بهصورت پیشفرض غیرفعال میشه. نتیجه؟ فاکتورهای خودکار از ERP ارسال نمیشن، Scan-to-Email پرینترها از کار میافته، آلرتهای مانیتورینگ به دست کسی نمیرسه و اسکریپتهای اتوماسیون خراب میشن. و در نیمه دوم ۲۰۲۷؟ حتی فعالسازی مجدد هم دیگه ممکن نیست.