Microsoft 365: міграція з Basic Auth 2026

Вступ: Чому 2026 рік стане роком революції автентифікації в Microsoft 365

Якщо ви IT-адміністратор і досі використовуєте базову автентифікацію (Basic Authentication) у вашій інфраструктурі Microsoft 365 — у вас проблема. І ні, це не з тих проблем, яку можна спокійно відкласти на «наступний квартал». Microsoft нарешті підвела жирну риску під багаторічним процесом відмови від застарілих протоколів, і 2026 рік стане точкою неповернення для цілої низки сервісів.

Отже, що ж таке базова автентифікація? По суті, це протокол, який передає ваше ім'я користувача та пароль у кожному запиті, фактично у відкритому вигляді. Так, Base64 — це не шифрування, а лише кодування (і якщо хтось у вашій команді вважає інакше — саме час провести розмову). Цей механізм був зручним у часи, коли безпека мережі вважалася розкішшю, а не повсякденною необхідністю.

Але сьогодні? Фішингові атаки стали щоденною реальністю, витоки облікових даних трапляються з лякаючою регулярністю, і Basic Auth перетворився на відчинені двері для зловмисників.

Microsoft розуміє це вже давно. Ще у 2022 році компанія почала вимикати базову автентифікацію для протоколів Exchange Online — POP, IMAP, ActiveSync, EWS. Але SMTP AUTH (той самий протокол, через який ваші принтери надсилають скани електронною поштою, а скрипти моніторингу відправляють сповіщення) залишався недоторканним. До тепер.

У 2026 році Microsoft завершує масштабну програму виведення з експлуатації базової автентифікації одразу в кількох напрямках: SMTP AUTH Client Submission, IDCRL-автентифікація у SharePoint Online та OneDrive, застарілі методи MFA та інші legacy-компоненти. Для IT-адміністраторів це означає одне — потрібно діяти зараз. Не завтра, не на наступному плановому засіданні, а сьогодні.

Цей посібник створено спеціально для українських IT-спеціалістів та адміністраторів helpdesk-служб. Ми розглянемо повний таймлайн змін, покажемо, як знайти все, що використовує Basic Auth у вашій організації, та дамо покрокові інструкції міграції для кожного сценарію — від принтерів до PowerShell-скриптів.

Що саме припиняє працювати і коли: повний таймлайн на 2026 рік

Щоб ефективно спланувати міграцію, треба чітко розуміти, які сервіси та протоколи зачіпає кожна хвиля змін. Ось консолідований таймлайн усіх ключових дат.

SMTP AUTH Basic Authentication: поетапне вимкнення

Це, мабуть, зміна з найбільшим практичним впливом на IT-інфраструктуру більшості організацій. Microsoft поетапно припиняє підтримку базової автентифікації для SMTP AUTH Client Submission — тобто прямої відправки пошти через smtp.office365.com на порту 587.

Дата	Подія	Вплив
1 березня 2026	Початок поетапного відхилення	Microsoft почне відхиляти невеликий відсоток SMTP-запитів з Basic Auth для моніторингу впливу
30 квітня 2026	100% відхилення для нових тенантів	Всі нові тенанти не зможуть використовувати Basic Auth для SMTP AUTH
Грудень 2026	Вимкнення за замовчуванням для існуючих тенантів	SMTP AUTH Basic Auth вимкнено за замовчуванням; адміністратори тимчасово зможуть увімкнути його знову

Важливий нюанс: У січні 2026 року Microsoft оновила таймлайн і надала існуючим тенантам додатковий час — до грудня 2026 замість попередньо запланованого повного вимкнення у квітні. Звучить як полегшення? Не поспішайте радіти. Microsoft починає поетапне відхилення вже з 1 березня 2026 року, тож частина ваших систем може перестати працювати значно раніше, ніж ви очікуєте.

Додатки та пристрої, які спробують використати SMTP AUTH з базовою автентифікацією після вимкнення, отримають таку помилку:

550 5.7.30 Basic authentication is not supported for Client Submission

Якщо бачите це у логах — вітаємо, ваш пристрій або додаток щойно «зламався». Але не панікуйте, далі ми покажемо, як це виправити.

IDCRL-автентифікація в SharePoint Online та OneDrive

IDCRL (Identity Client Runtime Library) — застарілий протокол автентифікації, який використовувався у SharePoint Online та OneDrive for Business. Microsoft замінює його на OpenID Connect та OAuth.

Дата	Подія	Вплив
16 лютого 2026	Блокування за замовчуванням	Застаріла клієнтська автентифікація блокується за замовчуванням для SharePoint Online та OneDrive
30 квітня 2026	Остаточний дедлайн	IDCRL-автентифікація блокується повністю, без можливості повторного увімкнення

Між 16 лютого та 30 квітня адміністратори ще мають можливість тимчасово повторно увімкнути IDCRL через PowerShell. Але після 30 квітня 2026 року — все, шлагбаум опускається назавжди. Якщо ваш код використовує клас SharePointOnlineCredentials — це пряма ознака IDCRL, і його потрібно мігрувати якнайшвидше.

Інші критичні зміни 2026 року

Зміна	Дата	Деталі
Застарілі методи MFA (legacy MFA/SSPR policies)	Вже припинено (вересень 2025)	Міграція на сучасну політику методів автентифікації в Entra ID є обов'язковою
Microsoft Publisher	Жовтень 2026	Повне видалення з підписок Microsoft 365
SharePoint legacy compliance features	Квітень 2026	Застарілі функції відповідності вимогам у SharePoint припиняють роботу

Вплив на IT-інфраструктуру: що саме зламається

Давайте будемо відверті: коли Microsoft каже «deprecated», IT-адміністратори чують «щось знову зламається у п'ятницю ввечері». І знаєте що? У цьому випадку побоювання цілком обґрунтовані.

Багатофункціональні принтери та сканери (MFP)

Чесно кажучи, це найболючіша тема. Більшість корпоративних принтерів та сканерів — HP, Ricoh, Xerox, Canon, Konica Minolta — використовують функцію Scan-to-Email, яка відправляє відскановані документи через SMTP AUTH з базовою автентифікацією. І ці пристрої, як правило, не підтримують OAuth 2.0. Особливо моделі, випущені до 2022 року.

Після вимкнення Basic Auth ваші сканери просто перестануть надсилати пошту. Користувачі прийдуть до вас зі словами «сканер зламався», хоча технічно зламалася автентифікація. Спробуйте пояснити це бухгалтеру, який терміново сканує рахунки-фактури — бажаю удачі.

Застарілі додатки та скрипти

Практично у кожній організації є набір скриптів та додатків, що надсилають листи через SMTP:

Системи моніторингу (Nagios, Zabbix, PRTG) — сповіщення про збої
Автоматизовані звіти — щоденні/щотижневі витяги з баз даних
CRM та ERP системи — нотифікації клієнтам і працівникам
PowerShell-скрипти з Send-MailMessage (до речі, цей командлет вже давно deprecated — якщо ви ще його використовуєте, це подвійна проблема)
LOB-додатки (Line of Business) — внутрішні бізнес-додатки, написані 10-15 років тому
Ticketing-системи — автоматичне створення тікетів через email

SharePoint-інтеграції з IDCRL

Якщо у вас є кастомні рішення на SharePoint, що використовують CSOM (Client-Side Object Model) з класом SharePointOnlineCredentials, вони перестануть працювати після блокування IDCRL. Під удар можуть потрапити:

Скрипти міграції даних
Автоматизовані процеси завантаження/вивантаження документів
Інтеграції з третіми системами (DMS, ECM)
Кастомні рішення на PowerShell для управління контентом SharePoint

Аудит: як знайти все, що використовує Basic Auth

Перш ніж братися за міграцію, потрібно провести ретельний аудит. Ви повинні точно знати, які пристрої, додатки та скрипти у вашій організації використовують базову автентифікацію. Інакше міграція перетвориться на гру «знайди, що ще зламалось» — повірте, це не та гра, в яку хочеться грати у робочий час.

1. Purview Audit Logs (для IDCRL у SharePoint)

Для виявлення IDCRL-автентифікації у SharePoint Online використовуйте Purview Audit Logs. Шукайте події з типом IDCRLSuccessSignIn:

Відкрийте Microsoft Purview Compliance Portal (compliance.microsoft.com)
Перейдіть до Audit → Search
У полі Activities знайдіть IDCRLSuccessSignIn
Виберіть потрібний діапазон дат
Запустіть пошук та проаналізуйте результати

Зверніть особливу увагу на поля ApplicationId, UserAgent та ClientIP — саме вони допоможуть ідентифікувати конкретні додатки й пристрої, що використовують IDCRL.

2. Azure AD (Entra ID) Sign-in Logs

Журнали входу Microsoft Entra ID (раніше Azure AD) — це, мабуть, найпотужніший інструмент для виявлення legacy-автентифікації:

Відкрийте Microsoft Entra admin center (entra.microsoft.com)
Перейдіть до Identity → Monitoring & health → Sign-in logs
Додайте фільтр: Client app → виберіть Legacy Authentication Clients
Зверніть увагу на Authenticated SMTP у списку legacy-клієнтів
Експортуйте результати для детального аналізу

Ці логи покажуть, які облікові записи використовуються для SMTP AUTH з Basic Auth, з яких IP-адрес надходять запити та яку частоту мають входи. Безцінна інформація для планування міграції.

3. Exchange Online PowerShell: перевірка стану SMTP AUTH

Для перевірки поточних налаштувань SMTP AUTH використовуйте наступні команди.

Перевірка глобального стану SMTP AUTH:

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

Якщо значення SmtpClientAuthenticationDisabled дорівнює $true — SMTP AUTH вимкнено на рівні організації. Якщо $false — увімкнено (це значення за замовчуванням).

Пошук поштових скриньок з увімкненим SMTP AUTH:

Get-CASMailbox -ResultSize Unlimited | Where {$_.SmtpClientAuthenticationDisabled -eq $false} | Select DisplayName, SmtpClientAuthenticationDisabled

Ця команда покаже всі поштові скриньки, для яких SMTP AUTH явно увімкнено. Саме ці облікові записи використовуються вашими додатками та пристроями для відправки пошти.

Розширена перевірка з експортом у CSV:

# Отримати повний список скриньок з SMTP AUTH та додатковими параметрами
Get-CASMailbox -ResultSize Unlimited |
    Where {$_.SmtpClientAuthenticationDisabled -eq $false} |
    Select DisplayName, PrimarySmtpAddress, SmtpClientAuthenticationDisabled,
           ActiveSyncEnabled, OWAEnabled |
    Export-Csv -Path "C:\Reports\SMTP_Auth_Mailboxes.csv" -NoTypeInformation -Encoding UTF8

Write-Host "Звіт збережено: C:\Reports\SMTP_Auth_Mailboxes.csv"

Порада: Обов'язково збережіть результати аудиту — цей список стане основою для планування міграції та відстеження прогресу.

Шлях міграції 1: OAuth 2.0 для SMTP AUTH

OAuth 2.0 — рекомендований Microsoft шлях для додатків і скриптів, які відправляють пошту через SMTP AUTH. На відміну від Basic Auth (де пароль летить у кожному запиті), OAuth використовує тимчасові маркери доступу з обмеженим терміном дії та прив'язкою до конкретних дозволів. Набагато безпечніше.

Крок 1: Реєстрація додатку в Microsoft Entra ID

Перейдіть до Microsoft Entra admin center (entra.microsoft.com)
Відкрийте Identity → Applications → App registrations
Натисніть New registration
Введіть ім'я додатку (наприклад, «SMTP OAuth Sender»)
У полі Supported account types виберіть «Accounts in this organizational directory only»
Натисніть Register
Запишіть Application (client) ID та Directory (tenant) ID — вони вам ще знадобляться

Крок 2: Налаштування дозволів

У зареєстрованому додатку перейдіть до API permissions
Натисніть Add a permission
Виберіть APIs my organization uses → знайдіть Office 365 Exchange Online
Виберіть Application permissions
Додайте дозвіл SMTP.SendAsApp
Натисніть Grant admin consent (потрібні права глобального адміністратора)

Крок 3: Створення клієнтського секрету

Перейдіть до Certificates & secrets
Натисніть New client secret
Задайте опис та термін дії (рекомендуємо 12-24 місяці)
Збережіть значення секрету — його буде показано лише один раз!

Порада для параноїків (тобто для хороших адміністраторів): замість клієнтського секрету краще використовувати сертифікат — це значно безпечніше. Секрети можуть витекти, сертифікати — набагато рідше.

Крок 4: Реєстрація Service Principal в Exchange Online

Після реєстрації додатку потрібно створити Service Principal у Exchange Online та надати йому дозволи на відправку пошти від імені конкретної скриньки:

# Встановлення та підключення до Exchange Online
Install-Module ExchangeOnlineManagement
Connect-ExchangeOnline

# Створення Service Principal
# Замініть <app-id> на Application (client) ID з Entra ID
# Замініть <object-id> на Object ID сервісного принципала з Enterprise Applications
New-ServicePrincipal -AppId <app-id> -ServiceId <object-id>

# Надання дозволів на відправку від імені конкретної скриньки
Add-MailboxPermission -Identity "[email protected]" -User <service-principal-id> -AccessRights FullAccess

Увага: Параметр -ServiceId — це Object ID з розділу Enterprise Applications, а не з App registrations! Це надзвичайно поширена помилка, яка може коштувати вам кількох годин дебагу. Я сам на це натрапляв — і не раз.

Крок 5: Отримання OAuth-токену та відправка пошти

Ось повний приклад на Python, який демонструє отримання токену та відправку листа через SMTP AUTH з OAuth 2.0:

import smtplib
import msal

config = {
    "client_id": "your-app-id",
    "client_secret": "your-client-secret",
    "authority": "https://login.microsoftonline.com/your-tenant-id",
    "scope": ["https://outlook.office365.com/.default"]
}

app = msal.ConfidentialClientApplication(
    config["client_id"],
    authority=config["authority"],
    client_credential=config["client_secret"]
)

result = app.acquire_token_for_client(scopes=config["scope"])
access_token = result["access_token"]

smtp = smtplib.SMTP("smtp.office365.com", 587)
smtp.ehlo()
smtp.starttls()
smtp.auth("XOAUTH2", lambda: f"[email protected]=Bearer {access_token}")
smtp.sendmail("[email protected]", ["[email protected]"], "Subject: Test\n\nTest message")
smtp.quit()

На що звернути увагу:

Бібліотека msal (Microsoft Authentication Library) отримує токен
Scope https://outlook.office365.com/.default запитує всі дозволи, надані додатку
SMTP-автентифікація використовує механізм XOAUTH2 замість простого логіну/пароля
Адреса [email protected] має відповідати скриньці, для якої налаштовано дозволи

Для PowerShell-скриптів аналогічний підхід реалізується через модуль MSAL.PS:

# Встановлення модуля MSAL.PS
Install-Module MSAL.PS -Force

# Отримання токену
$token = Get-MsalToken -ClientId "your-app-id" `
    -ClientSecret (ConvertTo-SecureString "your-client-secret" -AsPlainText -Force) `
    -TenantId "your-tenant-id" `
    -Scopes "https://outlook.office365.com/.default"

# Використання токену для SMTP (через .NET класи)
$smtpClient = New-Object System.Net.Mail.SmtpClient("smtp.office365.com", 587)
$smtpClient.EnableSsl = $true
# Примітка: для OAuth потрібно використовувати MailKit або іншу бібліотеку,
# що підтримує XOAUTH2 — стандартний SmtpClient .NET цього не вміє!

Шлях міграції 2: SMTP Relay для застарілих пристроїв

Коли ваш принтер Kyocera 2015 року випуску поняття не має, що таке OAuth, а бухгалтерія вимагає scan-to-email «прямо зараз» — SMTP Relay стає вашим рятівним колом. Цей метод не потребує автентифікації на рівні кожного пристрою, натомість покладається на IP-обмеження та TLS-шифрування.

Коли обирати SMTP Relay

Пристрої не підтримують OAuth 2.0 (більшість старих MFP — а це, на жаль, реальність багатьох офісів)
Потрібно надсилати пошту від імені вашого домену
Пристрої мають статичну IP-адресу або знаходяться у визначеній підмережі
Треба надсилати пошту як внутрішнім, так і зовнішнім отримувачам

Налаштування через Exchange Admin Center

Відкрийте Exchange Admin Center (admin.exchange.microsoft.com)
Перейдіть до Mail flow → Connectors
Натисніть Add a connector
Виберіть Connection from: Your organization's email server
Виберіть Connection to: Office 365
Налаштуйте автентифікацію за IP-адресою
Вкажіть IP-адреси ваших пристроїв або офісних мереж

Налаштування через PowerShell

# Створення вхідного конектора для SMTP Relay
New-InboundConnector -Name "SMTP Relay for Printers" `
    -ConnectorType OnPremises `
    -SenderIPAddresses "203.0.113.10" `
    -RestrictDomainsToIPAddresses $true

Налаштування на пристрої (принтері/сканері):

Параметр	Значення
SMTP-сервер	Ваш MX-запис (наприклад, contoso-com.mail.protection.outlook.com)
Порт	25
TLS	Увімкнено (обов'язково)
Автентифікація	Не потрібна (анонімна)
Адреса відправника	Повинна бути з вашого домену ([email protected])

Важливі обмеження, про які варто знати:

Порт 25 може бути заблокований вашим інтернет-провайдером — обов'язково уточніть це заздалегідь
IP-адреса пристрою має бути статичною та зовнішньою
Для відправки з динамічних IP цей метод не підходить
Потрібно правильно налаштувати SPF-записи, щоб включити IP-адреси пристроїв

Порада з досвіду: якщо ваші принтери за NAT, переконайтеся, що зовнішня IP-адреса офісу є статичною. Саме її потрібно вказати у конекторі. Звучить очевидно, але кількість тікетів через цю помилку — вражає.

Шлях міграції 3: High Volume Email (HVE) для Microsoft 365

High Volume Email — відносно нова функція Microsoft 365, яка з'явилася у публічному превью у квітні 2024 року. HVE створена для масової відправки електронної пошти внутрішнім отримувачам без звичних обмежень на кількість адресатів.

Ключові характеристики HVE

Параметр	Значення
Кількість HVE-акаунтів	До 100 на тенант
Отримувачі	Тільки внутрішні (у межах вашої організації)
Обмеження на отримувачів	Знято (на відміну від звичайних скриньок)
Basic Auth підтримка	До вересня 2028 року
OAuth підтримка	Доступна (рекомендовано)
Загальна доступність (GA)	Березень 2026

Коли використовувати HVE

Масові внутрішні розсилки — HR-повідомлення, оповіщення безпеки
Автоматизовані звіти для великої кількості внутрішніх отримувачів
Системні нотифікації від LOB-додатків для працівників
Сценарії, де звичайних лімітів Exchange Online просто недостатньо

Важливе обмеження: HVE працює виключно для внутрішніх отримувачів. Якщо потрібно надсилати пошту назовні — це не ваш варіант, дивіться Azure Communication Services нижче.

І ще один момент. Незважаючи на те, що HVE підтримуватиме Basic Auth аж до вересня 2028 року, Microsoft наполегливо рекомендує одразу використовувати OAuth. Я з ними згоден: якщо вже мігруєте — мігруйте нормально. Перехід на Basic Auth у HVE — це лише відтермінування неминучого.

Шлях міграції 4: Azure Communication Services

Для сценаріїв, де потрібна відправка пошти зовнішнім отримувачам — транзакційні листи, підтвердження замовлень, скидання паролів — Azure Communication Services (ACS) є рекомендованою альтернативою.

Переваги ACS

Сучасний REST API — легка інтеграція з будь-якою мовою програмування
SMTP-сумісність — ACS підтримує SMTP, тож можна мінімізувати зміни у коді
Автентифікація Entra ID — безпечна автентифікація через Microsoft Entra
SPF та DKIM — автоматичне налаштування для кращої доставленості
Масштабованість — хмарний сервіс без обмежень on-premises інфраструктури
Аналітика — детальна статистика доставки та взаємодій

Базове налаштування ACS

Створіть ресурс Azure Communication Services у порталі Azure
Підключіть Email Communication Service
Налаштуйте домен (Azure-managed або custom)
Для SMTP: налаштуйте автентифікацію через Entra ID та отримайте connection string
Для REST API: скористайтеся SDK потрібної мови програмування

Приклад відправки через REST API (Python):

from azure.communication.email import EmailClient

connection_string = "endpoint=https://<resource-name>.communication.azure.com/;accesskey=<access-key>"
client = EmailClient.from_connection_string(connection_string)

message = {
    "senderAddress": "DoNotReply@<your-domain>.azurecomm.net",
    "recipients": {
        "to": [{"address": "[email protected]", "displayName": "Отримувач"}]
    },
    "content": {
        "subject": "Тестове повідомлення від ACS",
        "plainText": "Це тестове повідомлення, надіслане через Azure Communication Services."
    }
}

poller = client.begin_send(message)
result = poller.result()
print(f"Статус відправки: {result['status']}")

Для legacy-систем, де зміна коду небажана, ACS підтримує SMTP-режим на порту 587 з автентифікацією через Entra ID. Це дозволяє змінити лише налаштування SMTP-сервера, не чіпаючи код додатку. Дуже зручно, якщо чесно.

Міграція SharePoint та OneDrive: від IDCRL до OAuth

Окрім SMTP AUTH, є другий великий фронт міграції — перехід від IDCRL до OAuth/OpenID Connect у SharePoint Online та OneDrive for Business. Якщо у вас є кастомні скрипти або додатки для SharePoint — ця секція саме для вас.

Як визначити, що ваш код використовує IDCRL

Головна ознака — клас SharePointOnlineCredentials у вашому коді. Якщо бачите щось подібне — це стовідсотково IDCRL:

// C# - СТАРИЙ КОД (IDCRL) - ПЕРЕСТАНЕ ПРАЦЮВАТИ!
var credentials = new SharePointOnlineCredentials(username, securePassword);
var context = new ClientContext(siteUrl);
context.Credentials = credentials;

Також перевірте Purview Audit Logs на наявність подій IDCRLSuccessSignIn, як описано в розділі аудиту.

Оновлення коду на MSAL (OAuth)

Замініть SharePointOnlineCredentials на автентифікацію через MSAL:

// C# - НОВИЙ КОД (OAuth/MSAL)
using Microsoft.Identity.Client;

var app = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithClientSecret(clientSecret)
    .WithAuthority(new Uri($"https://login.microsoftonline.com/{tenantId}"))
    .Build();

var authResult = await app.AcquireTokenForClient(
    new[] { $"https://{tenantName}.sharepoint.com/.default" })
    .ExecuteAsync();

var context = new ClientContext(siteUrl);
context.ExecutingWebRequest += (sender, e) =>
{
    e.WebRequestExecutor.RequestHeaders["Authorization"] =
        "Bearer " + authResult.AccessToken;
};

Для PowerShell:

# Підключення до SharePoint Online через PnP PowerShell з OAuth
Install-Module PnP.PowerShell -Force

# Інтерактивне підключення
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/mysite" -Interactive

# Або з app registration (для автоматизації)
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/mysite" `
    -ClientId "your-app-id" `
    -ClientSecret "your-client-secret" `
    -Tenant "contoso.onmicrosoft.com"

Тимчасове повторне увімкнення IDCRL

Якщо потрібен додатковий час для міграції (до 30 квітня 2026), можна тимчасово повторно увімкнути IDCRL:

# Тимчасове повторне увімкнення IDCRL (працює лише до 30 квітня 2026!)
Set-SPOTenant -LegacyAuthProtocolsEnabled $true

УВАГА: Це тимчасова міра, і тільки. Після 30 квітня 2026 цей параметр перестане діяти, і IDCRL буде заблоковано повністю та безповоротно. Не використовуйте це як привід відкладати міграцію — краще використайте цей час для тестування та переходу на OAuth.

Контрольний список для IT-адміністраторів

Ось покроковий план дій для успішної міграції. Чесно раджу роздрукувати його й повісити на стіну біля робочого місця — структурований підхід збереже вам і нерви, і робочі місця.

Проведіть повний аудит — визначте всі пристрої, додатки та скрипти, що використовують Basic Auth. Використовуйте Entra ID Sign-in logs, Purview Audit logs та PowerShell-команди з розділу аудиту.
Класифікуйте знайдені системи за категоріями:
- Можуть бути оновлені до OAuth (додатки, скрипти)
- Не підтримують OAuth (старі принтери, апаратне забезпечення)
- Можуть бути замінені хмарними альтернативами
Визначте шлях міграції для кожної системи:
- OAuth 2.0 SMTP AUTH — для сучасних додатків
- SMTP Relay — для принтерів та старих пристроїв
- HVE — для масових внутрішніх розсилок
- Azure Communication Services — для зовнішньої пошти
Зареєструйте необхідні додатки у Microsoft Entra ID та налаштуйте дозволи (SMTP.SendAsApp).
Налаштуйте SMTP Relay конектори для пристроїв, що не підтримують OAuth.
Оновіть код та скрипти — замініть Basic Auth на OAuth, замініть SharePointOnlineCredentials на MSAL.
Оновіть прошивки принтерів — HP, Ricoh, Xerox та інші виробники випустили оновлення з підтримкою OAuth. Перевірте, чи є апдейти для ваших моделей.
Протестуйте все у тестовому середовищі або на пілотній групі.
Задокументуйте нові налаштування — IP-адреси конекторів, App ID, дозволи, відповідальні особи.
Заплануйте поступовий перехід — не мігруйте все одночасно. Почніть з некритичних систем і переходьте до основних.
Вимкніть Basic Auth на рівні тенанту після завершення міграції:
```
Set-TransportConfig -SmtpClientAuthenticationDisabled $true
```
Налаштуйте моніторинг — створіть алерти для виявлення спроб Basic Auth після міграції.
Оновіть документацію helpdesk — підготуйте інструкції для служби підтримки щодо нових процедур та типових помилок.
Перевірте політики MFA — переконайтесь, що ви використовуєте сучасну політику методів автентифікації в Entra ID, а не застарілі legacy MFA/SSPR policies.
Заплануйте регулярний перегляд — перевіряйте логи входу щомісяця для виявлення нових систем на Basic Auth.

Усунення типових проблем міграції

Міграція рідко проходить гладко — це нормально. Ось найпоширеніші помилки, з якими ви зіткнетесь, та способи їх вирішення. Тримайте цей розділ під рукою.

Помилка: 550 5.7.30 Basic authentication is not supported for Client Submission

Причина: Додаток або пристрій намагається відправити пошту через SMTP AUTH з базовою автентифікацією, яку вже заблоковано.

Що робити:

Мігруйте додаток на OAuth 2.0 (Шлях 1)
Переведіть пристрій на SMTP Relay (Шлях 2)
Тимчасово: перевірте, чи не вимкнено SMTP AUTH на рівні скриньки або організації

Помилка: AADSTS7000218 — відсутній client_secret або client_assertion

Причина: При запиті OAuth-токену не передано клієнтський секрет або сертифікат.

Що робити:

Перевірте, що client_secret правильно вказаний у коді
Переконайтесь, що секрет не протермінувався (це трапляється частіше, ніж здається)
Створіть новий секрет у Entra ID, якщо старий вже недійсний

Помилка: AADSTS700016 — додаток не знайдено

Причина: Неправильний Application (client) ID або додаток не зареєстровано у вашому тенанті.

Що робити:

Перевірте правильність client_id (скопіюйте ще раз з порталу)
Переконайтесь, що додаток зареєстровано саме у потрібному тенанті
Перевірте tenant_id у параметрі authority

Помилка: 535 5.7.3 Authentication unsuccessful

Причина: OAuth-токен отримано, але SMTP-автентифікація не проходить.

Що робити:

Переконайтесь, що Service Principal створено в Exchange Online
Перевірте наявність дозволу SMTP.SendAsApp з admin consent
Переконайтесь, що Add-MailboxPermission виконано для правильної скриньки
Перевірте, що email у XOAUTH2-рядку відповідає скриньці з дозволами

Помилка: IDCRL-автентифікація заблокована у SharePoint

Причина: IDCRL заблоковано за замовчуванням з 16 лютого 2026.

Що робити:

Тимчасово: Set-SPOTenant -LegacyAuthProtocolsEnabled $true (до 30 квітня 2026)
Постійно: мігруйте код з SharePointOnlineCredentials на MSAL
Для PnP PowerShell: оновіть модуль і використовуйте Connect-PnPOnline -Interactive або -ClientId

Помилка: конектор SMTP Relay не працює

Причина: Неправильна конфігурація конектора або мережеві обмеження.

Що робити:

Перевірте, що зовнішня IP пристрою збігається з IP у конекторі
Переконайтесь, що порт 25 не заблоковано провайдером або фаєрволом
Перевірте, що TLS увімкнено на пристрої
Перевірте SPF-запис — він повинен включати IP-адресу пристрою
Використовуйте діагностичні команди для перевірки з'єднання:

# Перевірка з'єднання з MX-записом
Test-NetConnection -ComputerName contoso-com.mail.protection.outlook.com -Port 25

# Перевірка черги повідомлень (якщо є локальний поштовий сервер)
Get-Queue | Format-List Identity, Status, MessageCount, LastError

Помилка: «Mailbox unavailable» при OAuth

Причина: Додаток намагається надіслати від імені скриньки без відповідних дозволів Service Principal.

Що робити:

Перевірте, що Add-MailboxPermission виконано для тієї скриньки, яка вказана як відправник
Зачекайте до 30 хвилин після надання дозволів — зміни застосовуються не миттєво
Перевірте правильність email-адреси (одна літера — і все пропало)

Зведена таблиця кодів помилок

Код помилки	Опис	Найімовірніша причина
`550 5.7.30`	Basic auth not supported	Basic Auth заблоковано, потрібен OAuth або Relay
`535 5.7.3`	Authentication unsuccessful	Неправильний токен або відсутні дозволи Service Principal
`AADSTS7000218`	Missing client_secret	Не передано секрет або сертифікат при запиті токену
`AADSTS700016`	App not found	Неправильний client_id або tenant_id
`AADSTS70011`	Invalid scope	Неправильний scope; використовуйте `https://outlook.office365.com/.default`
`AADSTS650052`	App needs permission	Дозвіл SMTP.SendAsApp не надано або немає admin consent

Корисні ресурси та інструменти

Правильні інструменти роблять міграцію набагато простішою. Ось що вам знадобиться.

PowerShell-модулі для міграції

# Основні модулі для міграції
Install-Module ExchangeOnlineManagement    # Управління Exchange Online
Install-Module Microsoft.Graph             # Microsoft Graph API
Install-Module PnP.PowerShell              # SharePoint Online (PnP)
Install-Module MSAL.PS                     # OAuth-токени
Install-Module Microsoft.Online.SharePoint.PowerShell  # SPO Management Shell

Інструменти перевірки підключення

Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) — тестування SMTP AUTH, POP, IMAP
Message Trace у Exchange Admin Center — відстеження доставки повідомлень
Entra ID Sign-in logs — моніторинг автентифікації в реальному часі
Fiddler або Postman — для тестування OAuth-потоків та REST API

Скрипт комплексного аудиту Basic Auth

Цей PowerShell-скрипт автоматизує основні кроки аудиту — просто запустіть його і отримайте повну картину:

# Комплексний скрипт аудиту Basic Auth у Microsoft 365
# Запускайте від імені адміністратора Exchange Online

# Підключення
Connect-ExchangeOnline

Write-Host "=== АУДИТ БАЗОВОЇ АВТЕНТИФІКАЦІЇ ===" -ForegroundColor Cyan
Write-Host ""

# 1. Глобальний стан SMTP AUTH
Write-Host "[1] Глобальний стан SMTP AUTH:" -ForegroundColor Yellow
$transportConfig = Get-TransportConfig
if ($transportConfig.SmtpClientAuthenticationDisabled) {
    Write-Host "  SMTP AUTH вимкнено на рівні організації (добре!)" -ForegroundColor Green
} else {
    Write-Host "  SMTP AUTH увімкнено на рівні організації (потрібна увага!)" -ForegroundColor Red
}

# 2. Скриньки з увімкненим SMTP AUTH
Write-Host ""
Write-Host "[2] Скриньки з явно увімкненим SMTP AUTH:" -ForegroundColor Yellow
$smtpMailboxes = Get-CASMailbox -ResultSize Unlimited |
    Where {$_.SmtpClientAuthenticationDisabled -eq $false}

if ($smtpMailboxes.Count -gt 0) {
    Write-Host "  Знайдено $($smtpMailboxes.Count) скриньок:" -ForegroundColor Red
    $smtpMailboxes | Select DisplayName, PrimarySmtpAddress | Format-Table -AutoSize

    # Експорт у CSV
    $smtpMailboxes | Select DisplayName, PrimarySmtpAddress, SmtpClientAuthenticationDisabled |
        Export-Csv -Path ".\BasicAuth_SMTP_Audit.csv" -NoTypeInformation -Encoding UTF8
    Write-Host "  Результати збережено у BasicAuth_SMTP_Audit.csv" -ForegroundColor Green
} else {
    Write-Host "  Скриньок з увімкненим SMTP AUTH не знайдено (відмінно!)" -ForegroundColor Green
}

# 3. Відключення
Disconnect-ExchangeOnline -Confirm:$false
Write-Host ""
Write-Host "=== АУДИТ ЗАВЕРШЕНО ===" -ForegroundColor Cyan

Особливі сценарії та рекомендації

Сценарій 1: Гібридне середовище Exchange

Якщо у вас гібрид Exchange (On-Premises + Online), ситуація трохи складніша. Локальний Exchange Server і далі підтримуватиме Basic Auth для SMTP, але якщо пошта маршрутизується через Exchange Online — мігрувати все одно доведеться. Найкращий підхід: налаштуйте SMTP Relay через локальний Exchange як проміжний хоп, щоб legacy-пристрої відправляли пошту локально, а маршрутизація до хмари йшла через гібридний конектор.

Сценарій 2: Мультитенантне середовище (MSP/CSP)

Керуєте кількома тенантами як MSP або CSP? Тоді аудит та міграцію потрібно проводити для кожного тенанту окремо. Автоматизуйте процес за допомогою скрипту аудиту та Microsoft Graph API. І так — реєстрація додатків у Entra ID теж має бути виконана в кожному тенанті. Масштаб роботи серйозний, але іншого варіанту немає.

Сценарій 3: Пристрої IoT та вбудовані системи

Системи контролю доступу, HVAC-контролери, відеонагляд — багато IoT-пристроїв відправляють сповіщення електронною поштою через SMTP. Можливості для оновлення у них зазвичай мінімальні, тож SMTP Relay — єдиний реалістичний варіант. А якщо пристрої не підтримують навіть TLS (так, таке буває), розгляньте встановлення локального SMTP-шлюзу на кшталт hMailServer або Postfix, який прийматиме пошту від пристроїв і пересилатиме її до Microsoft 365 через конектор.

Сценарій 4: Міграція Send-MailMessage у PowerShell

Командлет Send-MailMessage deprecated і не підтримує OAuth. Якщо він є у ваших скриптах — час його замінити. Ось два основні варіанти.

# Варіант 1: Microsoft Graph API (рекомендовано)
Install-Module Microsoft.Graph.Users.Actions

Connect-MgGraph -ClientId "your-app-id" -TenantId "your-tenant-id" -CertificateThumbprint "your-cert-thumbprint"

$params = @{
    Message = @{
        Subject = "Тестове повідомлення через Graph API"
        Body = @{
            ContentType = "Text"
            Content = "Це повідомлення надіслано через Microsoft Graph API замість Send-MailMessage."
        }
        ToRecipients = @(
            @{
                EmailAddress = @{
                    Address = "[email protected]"
                }
            }
        )
    }
    SaveToSentItems = "false"
}

Send-MgUserMail -UserId "[email protected]" -BodyParameter $params

# Варіант 2: MailKit для OAuth SMTP (для .NET/PowerShell)
# Потрібно встановити: Install-Package MailKit
Add-Type -Path "path\to\MailKit.dll"
Add-Type -Path "path\to\MimeKit.dll"

$message = New-Object MimeKit.MimeMessage
$message.From.Add("[email protected]")
$message.To.Add("[email protected]")
$message.Subject = "Тестове повідомлення"
$message.Body = New-Object MimeKit.TextPart("plain") -Property @{ Text = "Тест OAuth SMTP" }

$smtp = New-Object MailKit.Net.Smtp.SmtpClient
$smtp.Connect("smtp.office365.com", 587, [MailKit.Security.SecureSocketOptions]::StartTls)

# OAuth автентифікація
$oauth2 = New-Object MailKit.Security.SaslMechanismOAuth2("[email protected]", $accessToken)
$smtp.Authenticate($oauth2)

$smtp.Send($message)
$smtp.Disconnect($true)

Планування комунікації зі стейкхолдерами

Міграція автентифікації — це не лише технічна задача. Вам потрібно правильно комунікувати зміни, і від того, наскільки добре ви це зробите, залежить, чи отримаєте бюджет і підтримку вчасно.

Що повідомити керівництву

Microsoft примусово вимикає застарілу автентифікацію — це не наша ініціатива, це вимога вендора
Без міграції пошта від принтерів, сканерів та автоматизованих систем перестане працювати
Потрібен бюджет на оновлення прошивок, і, можливо, на заміну застарілого обладнання
Міграція суттєво покращує безпеку організації

Що повідомити кінцевим користувачам

Scan-to-email може тимчасово не працювати під час міграції
Деякі автоматичні сповіщення можуть тимчасово припинитися
Ніяких дій від користувачів не потрібно (у більшості випадків)
Якщо щось перестало працювати — повідомте helpdesk з описом проблеми

Що повідомити команді helpdesk

Очікуйте зростання кількості звернень щодо проблем із відправкою пошти
Ключова помилка: 550 5.7.30 — означає, що пристрій або додаток потребує міграції
Ескалюйте такі звернення до команди інфраструктури — це не проблема кінцевого користувача
Підготуйте шаблони відповідей для типових звернень

Висновок: час діяти — зараз

Якщо ви дочитали цю статтю до кінця — щиро вітаю, ви вже на крок попереду. Але читання — це лише початок. Таймлайн міграції жорсткий і недвозначний:

16 лютого 2026 — IDCRL заблоковано за замовчуванням у SharePoint Online
1 березня 2026 — початок поетапного відхилення SMTP AUTH Basic Auth
30 квітня 2026 — повне блокування IDCRL без можливості увімкнення
Грудень 2026 — SMTP AUTH Basic Auth вимкнено для всіх існуючих тенантів

Це не гіпотетичні загрози. Microsoft вже неодноразово демонструвала серйозність намірів. У 2022 році компанія вимкнула базову автентифікацію для POP, IMAP, ActiveSync та EWS в Exchange Online — і зробила це навіть раніше за деякі оголошені дати.

Ваш план дій на найближчий тиждень:

Сьогодні: Запустіть скрипт аудиту та перевірте Sign-in logs
Цього тижня: Складіть реєстр усіх систем на Basic Auth
Наступного тижня: Визначте шлях міграції для кожної системи
Протягом місяця: Почніть тестування OAuth та SMTP Relay
Протягом двох місяців: Завершіть міграцію критичних систем

Базова автентифікація — це реліквія минулого, яка тримала двері вашої організації відчиненими. OAuth 2.0, сучасні методи MFA та хмарні сервіси відправки пошти — це не просто «нові технології заради технологій». Це фундаментальне покращення безпеки.

Так, міграція вимагає зусиль. Так, деякі принтери доведеться налаштовувати руками. Так, будуть нічні зміни й тікети від незадоволених користувачів. Але альтернатива — вразлива автентифікація та зламані поштові потоки — незрівнянно гірша.

Дійте зараз. Ваш таймлайн уже почався.

Вступ: Чому 2026 рік стане роком революції автентифікації в Microsoft 365

Що саме припиняє працювати і коли: повний таймлайн на 2026 рік

SMTP AUTH Basic Authentication: поетапне вимкнення

IDCRL-автентифікація в SharePoint Online та OneDrive

Інші критичні зміни 2026 року

Вплив на IT-інфраструктуру: що саме зламається

Багатофункціональні принтери та сканери (MFP)

Застарілі додатки та скрипти

SharePoint-інтеграції з IDCRL

Аудит: як знайти все, що використовує Basic Auth

1. Purview Audit Logs (для IDCRL у SharePoint)

2. Azure AD (Entra ID) Sign-in Logs

3. Exchange Online PowerShell: перевірка стану SMTP AUTH

Шлях міграції 1: OAuth 2.0 для SMTP AUTH

Крок 1: Реєстрація додатку в Microsoft Entra ID

Крок 2: Налаштування дозволів

Крок 3: Створення клієнтського секрету

Крок 4: Реєстрація Service Principal в Exchange Online

Крок 5: Отримання OAuth-токену та відправка пошти

Шлях міграції 2: SMTP Relay для застарілих пристроїв

Коли обирати SMTP Relay

Налаштування через Exchange Admin Center

Налаштування через PowerShell

Шлях міграції 3: High Volume Email (HVE) для Microsoft 365

Ключові характеристики HVE

Коли використовувати HVE

Шлях міграції 4: Azure Communication Services

Переваги ACS

Базове налаштування ACS

Міграція SharePoint та OneDrive: від IDCRL до OAuth

Як визначити, що ваш код використовує IDCRL

Оновлення коду на MSAL (OAuth)

Тимчасове повторне увімкнення IDCRL

Контрольний список для IT-адміністраторів

Усунення типових проблем міграції

Помилка: 550 5.7.30 Basic authentication is not supported for Client Submission

Помилка: AADSTS7000218 — відсутній client_secret або client_assertion

Помилка: AADSTS700016 — додаток не знайдено

Помилка: 535 5.7.3 Authentication unsuccessful

Помилка: IDCRL-автентифікація заблокована у SharePoint

Помилка: конектор SMTP Relay не працює

Помилка: «Mailbox unavailable» при OAuth

Зведена таблиця кодів помилок

Корисні ресурси та інструменти

PowerShell-модулі для міграції

Інструменти перевірки підключення

Скрипт комплексного аудиту Basic Auth

Особливі сценарії та рекомендації

Сценарій 1: Гібридне середовище Exchange

Сценарій 2: Мультитенантне середовище (MSP/CSP)

Сценарій 3: Пристрої IoT та вбудовані системи

Сценарій 4: Міграція Send-MailMessage у PowerShell

Планування комунікації зі стейкхолдерами

Що повідомити керівництву

Що повідомити кінцевим користувачам

Що повідомити команді helpdesk

Висновок: час діяти — зараз

Пов'язані Статті

VPN не підключається у Windows 11: діагностика та виправлення помилок

Мережевий принтер не працює у Windows 11: діагностика та усунення несправностей

Діагностика та усунення несправностей Active Directory: повний посібник для IT-підтримки у 2026 році