Fin de SMTP AUTH Basic dans Microsoft 365 : migrer imprimantes, applications et alertes vers OAuth

La fin de décembre 2026 est un jalon, pas une permission d’attendre

Microsoft prévoit de désactiver SMTP AUTH avec authentification Basic par défaut dans les locataires Exchange Online existants à la fin de décembre 2026. Un administrateur pourra encore le réactiver au besoin. Pour les nouveaux locataires créés après cette période, OAuth sera la méthode prise en charge par défaut. Microsoft prévoit annoncer la date de retrait définitif au deuxième semestre de 2027.

La nuance est importante : il ne s’agit pas encore d’une coupure irréversible pour tous les locataires en décembre. Il s’agit néanmoins d’un changement de sécurité conçu pour faire ressortir les dernières dépendances. Réactiver Basic sans échéance ne ferait que reporter une panne et conserver un mot de passe réutilisable dans une imprimante, un script ou une application rarement inspectée.

Le bon objectif est donc simple : savoir exactement qui envoie par smtp.office365.com, migrer chaque flux vers une méthode adaptée, puis retirer l’exception. Les systèmes critiques méritent un test complet de livraison, pas seulement un message accepté par le serveur SMTP.

• Microsoft Exchange Team — Nouvel échéancier de SMTP AUTH Basic ↗
• Microsoft — Authentifier SMTP avec OAuth ↗

Ce qui disparaît, et ce qui reste disponible

SMTP AUTH est le protocole de soumission; Basic et OAuth sont deux façons de s’y authentifier. La fin annoncée vise le couple SMTP AUTH + nom d’utilisateur et mot de passe. Une application compatible peut continuer d’utiliser smtp.office365.com avec STARTTLS et XOAUTH2. Vous pouvez aussi abandonner SMTP pour Microsoft Graph ou utiliser un relais Exchange Online identifié par certificat ou adresse IP publique.

Ne confondez pas non plus l’authentification d’un utilisateur et celle d’une charge de travail. Un client interactif peut obtenir un jeton délégué au nom d’une personne. Un service sans interface utilise plutôt sa propre identité, un certificat ou une identité fédérée, puis une permission limitée aux boîtes dont il a réellement besoin.

Enfin, OAuth ne corrige pas un vieux chiffrement. La soumission SMTP exige TLS 1.2 ou 1.3, et Microsoft recommande le port 587 avec STARTTLS. Un appareil qui ne sait ni obtenir un jeton ni négocier TLS moderne doit passer par une autre architecture.

• Microsoft — Méthodes d’envoi pour imprimantes et applications ↗

Commencer par 90 jours de données, puis parler aux propriétaires

Dans le Centre d’administration Exchange, le rapport SMTP AUTH Clients se trouve sous Reports > Mail Flow. Il distingue Basic Auth, affiché comme TlsAuthLogin, de Modern Auth, affiché comme XOAUTH2. Il montre aussi l’expéditeur, le volume et la version TLS. Étendez la plage jusqu’à 90 jours et exportez le CSV; sept jours ne suffisent pas pour un rapport mensuel, une alerte de certificat ou une tâche de paie.

Le rapport ne connaît toutefois pas le nom de l’imprimante ou le responsable de l’ERP. Croisez l’adresse d’expédition, l’adresse IP, les journaux du pare-feu, la trace de messages et les configurations locales. Demandez aux équipes applicatives quelle fonction déclenche le courriel, à qui il est destiné, et ce qui arrive si l’envoi échoue.

Créez un registre par flux, pas seulement par compte. Un même compte alerts@ peut cacher dix systèmes avec des contraintes différentes. Séparer ces flux permet de migrer un appareil à la fois, de révoquer une intégration sans casser les autres et d’attribuer un propriétaire réel.

• Microsoft — Rapport SMTP AUTH Clients ↗
• Microsoft — Trace des messages dans Exchange Online ↗

Choisir la cible selon le système, pas selon une recette unique

Le meilleur remplacement est souvent celui que le produit prend officiellement en charge. Une imprimante récente peut obtenir un jeton OAuth dans son interface Web; un ERP peut offrir un connecteur Microsoft 365; une application interne peut appeler Graph; un vieux contrôleur peut seulement joindre un relais local. Forcer la même solution partout augmente les privilèges et le dépannage.

Exigez la documentation du fournisseur et la version minimale du micrologiciel ou du logiciel. La présence d’un bouton OAuth ne garantit pas le flux application-only, les boîtes partagées ni une rotation de certificat. Testez aussi l’expéditeur, les destinataires externes, les pièces jointes et le renouvellement du jeton.

Lire les réglages Exchange Online avant de les changer

Exchange Online possède un réglage global et un réglage par boîte. À la boîte, $null hérite du locataire, $true désactive SMTP AUTH et $false l’active explicitement. Cette dernière valeur peut survivre à un durcissement global; inventoriez donc les exceptions avant et après le changement.

Les paramètres de sécurité Entra désactivent SMTP AUTH. Une stratégie d’authentification Exchange peut aussi bloquer Basic. Ne désactivez pas ces protections à l’échelle du locataire pour faire fonctionner un seul appareil : choisissez un autre chemin ou une exception nominative, documentée et temporaire.

Connect-ExchangeOnline

Get-TransportConfig |
  Select-Object SmtpClientAuthenticationDisabled

Get-CASMailbox -ResultSize Unlimited |
  Select-Object DisplayName, PrimarySmtpAddress, SmtpClientAuthenticationDisabled |
  Export-Csv .\smtp-auth-mailboxes.csv -NoTypeInformation -Encoding UTF8

Get-OrganizationConfig |
  Select-Object DefaultAuthenticationPolicy

Get-AuthenticationPolicy |
  Select-Object Name, AllowBasicAuthSmtp

# $false active SMTP AUTH pour cette boîte; OAuth demeure préférable.
Set-CASMailbox -Identity alerts@contoso.com `
  -SmtpClientAuthenticationDisabled $false

Get-CASMailbox -Identity alerts@contoso.com |
  Select-Object PrimarySmtpAddress, SmtpClientAuthenticationDisabled

• Microsoft — Activer ou désactiver SMTP AUTH ↗
• Microsoft — Bloquer l’authentification Basic avec des stratégies ↗

Choisir OAuth délégué ou application-only

Le flux délégué convient lorsque l’utilisateur est présent et que l’application agit en son nom. Pour SMTP, l’étendue déléguée est https://outlook.office.com/SMTP.Send; offline_access permet d’obtenir un jeton d’actualisation lorsque le scénario le justifie. Le client doit savoir ouvrir une connexion, gérer le consentement et renouveler ses jetons.

Le flux application-only convient à un service, une tâche ou une passerelle sans utilisateur. La charge de travail demande un jeton pour https://outlook.office365.com/.default et Exchange autorise ensuite l’identité d’application à envoyer pour un périmètre de boîtes. Un certificat ou une identité fédérée est préférable à un secret statique lorsqu’ils sont pris en charge.

Pour un nouveau déploiement SMTP application-only, le modèle RBAC for Applications d’Exchange permet d’accorder le rôle Application SMTP.SendAsApp à un ensemble précis de boîtes. Il évite une permission non limitée à toutes les boîtes dans Entra. Les autorisations Entra et RBAC étant additives, retirez toute ancienne permission globale qui annulerait ce cloisonnement.

• Microsoft — OAuth pour SMTP, IMAP et POP ↗
• Microsoft — Accès application-only avec Microsoft Graph ↗

Configurer SMTP OAuth application-only avec un périmètre Exchange

Créez d’abord une inscription d’application monolocataire et son principal de service Entra. Dans le modèle RBAC recommandé pour SMTP, n’ajoutez pas la permission Exchange Online SMTP.SendAsApp dans la page API permissions : le rôle et sa portée sont accordés dans Exchange. Utilisez l’Object ID de l’application d’entreprise, pas l’Object ID affiché dans App registrations, lorsque vous créez le pointeur Exchange.

L’exemple suivant limite l’application aux membres directs d’un groupe de sécurité à extension messagerie. Les groupes imbriqués ne sont pas inclus. Remplacez tous les identifiants et le distinguished name; testez une boîte autorisée et une boîte volontairement hors périmètre. Les changements peuvent prendre de 30 minutes à deux heures dans le cache d’autorisation, même si Test-ServicePrincipalAuthorization reflète déjà la configuration.

Connect-ExchangeOnline

New-ServicePrincipal `
  -AppId 11111111-1111-1111-1111-111111111111 `
  -ObjectId 22222222-2222-2222-2222-222222222222 `
  -DisplayName "SMTP OAuth - ERP"

# Utiliser le DistinguishedName réel d’un groupe à extension messagerie.
New-ManagementScope `
  -Name "SMTP OAuth Senders" `
  -RecipientRestrictionFilter "MemberOfGroup -eq 'CN=SMTP OAuth Senders,OU=contoso.onmicrosoft.com,DC=COM'"

New-ManagementRoleAssignment `
  -Name "ERP SMTP OAuth" `
  -Role "Application SMTP.SendAsApp" `
  -App 11111111-1111-1111-1111-111111111111 `
  -CustomResourceScope "SMTP OAuth Senders"

Test-ServicePrincipalAuthorization `
  -Identity 11111111-1111-1111-1111-111111111111 `
  -Resource alerts@contoso.com | Format-Table

Test-ServicePrincipalAuthorization `
  -Identity 11111111-1111-1111-1111-111111111111 `
  -Resource direction@contoso.com | Format-Table

• Microsoft — Intégrer SMTP à RBAC for Applications ↗
• Microsoft — RBAC for Applications dans Exchange Online ↗

XOAUTH2 remplace le mot de passe dans la conversation SMTP

Après avoir obtenu un jeton, le client se connecte à smtp.office365.com, négocie STARTTLS puis utilise SASL XOAUTH2. La chaîne encodée contient l’adresse d’expédition et Bearer suivi du jeton, séparés par le caractère Control-A. Le jeton est court, lié à une audience et renouvelé par l’application; il ne faut jamais l’enregistrer dans un journal de débogage.

Une réponse 235 confirme seulement l’authentification. Le client doit encore envoyer le message, traiter les réponses SMTP et conserver les erreurs. Une réponse 535 indique souvent une mauvaise audience, une permission absente, une boîte hors portée, SMTP AUTH désactivé ou une configuration encore en propagation.

base64(
  "user=alerts@contoso.com" + Control-A +
  "auth=Bearer <ACCESS_TOKEN>" + Control-A + Control-A
)

AUTH XOAUTH2 <CHAINE_BASE64>

Serveur : smtp.office365.com
Port : 587
Sécurité : STARTTLS
TLS : 1.2 ou 1.3
Authentification : OAuth 2.0 / XOAUTH2
Audience application-only : https://outlook.office365.com/.default

• Microsoft — Format SASL XOAUTH2 et échange SMTP ↗

Pour une application modifiable, Microsoft Graph est souvent plus simple

Graph évite de maintenir une conversation SMTP et expose l’opération POST /users/{id}/sendMail. La permission Mail.Send existe en mode délégué ou application. Une réponse HTTP 202 signifie que la demande a été acceptée, pas que le destinataire a reçu le message; surveillez les échecs de transport et utilisez la trace de messages comme avec SMTP.

Le module Microsoft Graph PowerShell convient aux scripts. L’exemple utilise un certificat dans le magasin local plutôt qu’un secret écrit dans le fichier. Pour une application-only, limitez Application Mail.Send aux boîtes d’expédition requises avec RBAC for Applications et retirez toute permission Entra globale équivalente qui rendrait la portée inutile.

Connect-MgGraph `
  -TenantId "33333333-3333-3333-3333-333333333333" `
  -ClientId "11111111-1111-1111-1111-111111111111" `
  -CertificateThumbprint "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

$message = @{
  message = @{
    subject = "Alerte : espace disque faible"
    body = @{
      contentType = "Text"
      content = "SRV-FICHIERS01 a moins de 10 % d’espace libre."
    }
    toRecipients = @(
      @{ emailAddress = @{ address = "operations@contoso.com" } }
    )
  }
  saveToSentItems = $true
}

Send-MgUserMail `
  -UserId "alerts@contoso.com" `
  -BodyParameter $message

Disconnect-MgGraph

• Microsoft — API sendMail de Microsoft Graph ↗
• Microsoft — Restreindre Mail.Send avec RBAC for Applications ↗

Les imprimantes anciennes ont besoin d’un relais, pas d’un faux OAuth

Si le fabricant offre un micrologiciel OAuth pour Microsoft 365, testez-le d’abord. Confirmez la méthode de consentement, la boîte d’expédition, le renouvellement du jeton et les fonctions secondaires : numérisation, télécopie Internet, rapports de compteur et alertes techniques n’utilisent pas toujours le même profil SMTP.

Si l’appareil ne prend pas OAuth en charge, placez-le dans un VLAN dédié et autorisez-le à joindre seulement une passerelle SMTP contrôlée. La passerelle peut ensuite envoyer par Graph, SMTP OAuth, Azure Communication Services Email ou un connecteur Exchange Online. Elle ne doit accepter que les adresses IP prévues, les expéditeurs autorisés et les destinations nécessaires; un relais ouvert transforme rapidement un problème de compatibilité en incident.

Le relais Exchange Online vers le point de terminaison MX utilise le port 25 et identifie la source par certificat — recommandé — ou par adresse IP publique statique non partagée. Il n’exige pas de boîte licenciée et accepte des destinataires externes. Il ne convient pas à une application hébergée chez un tiers ou dans Azure si cette source ne respecte pas les exigences du connecteur.

• Microsoft — Relais SMTP et Direct Send ↗
• Microsoft — Envoi SMTP avec Azure Communication Services ↗

Durcir la passerelle et le connecteur

Une passerelle concentre les flux; traitez-la comme une infrastructure de sécurité. Deux instances peuvent être nécessaires si une panne empêche les alertes ou les numérisations essentielles. Centralisez les journaux, synchronisez l’heure, appliquez les correctifs et testez la file d’attente après chaque changement.

N’autorisez jamais tout le VLAN utilisateur à relayer. Utilisez une liste précise d’IP sources, refusez les domaines From non approuvés, limitez la taille et le débit, et empêchez la passerelle de remettre du courrier directement à Internet. Si le connecteur Exchange s’appuie sur une IP, surveillez le changement d’adresse publique; si un certificat est utilisé, alertez bien avant son expiration.

• Source : IP réservées des imprimantes et applications, jamais 0.0.0.0/0.
• Expéditeur : domaine accepté et adresses approuvées par système.
• Destination : interne seulement lorsque le besoin le permet.
• Transport : TLS 1.2 ou 1.3 sur tous les segments capables de le prendre en charge.
• Journalisation : source, From, destinataire, identifiant de message, résultat et latence.
• Secrets : certificat non exportable ou identité de charge de travail; aucune clé dans les scripts.
• Exploitation : file d’attente, reprise, certificat, espace disque et mises à jour supervisés.

Migrer scripts, applications et alertes sans perdre les erreurs

Un vieux script ne devient pas fiable simplement parce qu’il appelle Graph. Conservez le même contrat d’exploitation : destinataire, pièce jointe, identité From, priorité, journal, alerte en cas d’échec et mécanisme de reprise. Remplacez Send-MailMessage et les nouveaux développements fondés sur System.Net.Mail.SmtpClient par Graph ou une bibliothèque SMTP qui prend réellement XOAUTH2 en charge.

Pour les alertes, éliminez le cercle vicieux où le même service de courriel doit signaler sa propre panne. Ajoutez un canal indépendant — webhook Teams, plateforme de supervision, SMS ou service transactionnel — pour les alertes critiques de messagerie. Un test quotidien de bout en bout avec un identifiant unique permet de détecter une livraison silencieusement interrompue.

• Tester un message texte, HTML et avec la plus grosse pièce jointe attendue.
• Confirmer From, Reply-To, destinataires externes, groupes et boîtes partagées.
• Traiter les codes 429, 4xx SMTP et erreurs temporaires avec attente exponentielle.
• Conserver un identifiant de corrélation sans écrire le jeton ni le contenu sensible.
• Définir combien de temps le message peut attendre avant d’être déclaré en échec.
• Faire expirer les certificats et secrets dans un environnement de test pour valider l’alerte.

• Microsoft — SmtpClient n’est pas recommandé pour les nouveaux développements ↗
• Microsoft — Limites d’envoi Exchange Online ↗

Déployer par vagues avec un retour arrière court

Commencez par un flux visible, non vital et représentatif. Exécutez l’ancien et le nouveau chemin en parallèle seulement si l’application peut éviter les doublons. Sinon, préparez le retour arrière, changez le point de terminaison, testez les destinataires réels et observez les journaux pendant une période définie.

La réussite d’une vague ne se mesure pas au nombre de configurations modifiées. Elle se mesure au nombre de courriels attendus reçus, au nombre d’erreurs traitées et à la suppression de l’ancien secret. Fermez chaque vague avec le propriétaire du service, puis passez à la suivante.

Diagnostiquer dans l’ordre, sans réactiver Basic au premier 535

Commencez par le réseau et TLS, puis le jeton, puis l’autorisation Exchange. Décodez uniquement les en-têtes du jeton dans un outil approuvé et sans l’envoyer sur un site public : l’audience doit correspondre à Outlook pour SMTP ou à Graph pour sendMail, le locataire doit être le bon et le jeton ne doit pas être expiré.

Testez ensuite l’identité d’application et la boîte avec Test-ServicePrincipalAuthorization. Confirmez que SMTP AUTH n’est pas désactivé pour la boîte, attendez la propagation RBAC et inspectez le From. Un code 5.7.60 signale typiquement que l’identité authentifiée n’a pas le droit d’envoyer comme l’adresse choisie.

Retirer Basic et prouver que la migration tient

Lorsque le rapport ne montre plus TlsAuthLogin pour les flux prévus, bloquez Basic par stratégie, observez, puis désactivez SMTP AUTH globalement si aucun usage OAuth SMTP ne doit rester. Si des applications utilisent encore SMTP OAuth, gardez le protocole désactivé globalement et activez seulement les boîtes nécessaires, selon les protections Entra et Exchange de votre locataire.

Une exception Basic doit avoir un propriétaire, une justification, une adresse source, une alerte et une date d’expiration. Sa réactivation est un retour arrière, pas une architecture finale. Examinez chaque semaine le rapport SMTP AUTH pendant la transition, puis intégrez-le à la revue mensuelle Microsoft 365.

• Le rapport sur 90 jours ne révèle aucun client Basic sans propriétaire.
• Chaque expéditeur possède une méthode cible, une portée et une supervision.
• Les comptes partagés et mots de passe stockés ont été retirés.
• Les applications Graph et SMTP sont limitées aux boîtes nécessaires.
• Les imprimantes héritées passent par un relais fermé et segmenté.
• Les essais couvrent destinataires externes, pièces jointes et reprise après erreur.
• Le canal d’alerte du système de messagerie ne dépend pas uniquement de lui-même.
• Les exceptions restantes expirent automatiquement ou déclenchent une révision.

# Une boîte migrée vers Graph ou un autre service
Set-CASMailbox -Identity old-scanner@contoso.com `
  -SmtpClientAuthenticationDisabled $true

# Lorsque plus aucun flux SMTP AUTH, Basic ou OAuth, n’est requis
Set-TransportConfig -SmtpClientAuthenticationDisabled $true

Get-TransportConfig |
  Select-Object SmtpClientAuthenticationDisabled

• Microsoft — Paramètres SMTP AUTH du locataire et des boîtes ↗
• Microsoft — Diagnostic d’envoi pour appareils et applications ↗