Microsoft a annoncé la fin de l'authentification Basic pour SMTP AUTH dans Exchange Online. Les premiers équipements à tomber en panne seront ceux dont personne ne se souvient de la configuration : scanners, imprimantes multifonctions et vieux serveurs applicatifs dont le mot de passe de boîte aux lettres a été saisi dans un formulaire web. Le calendrier de retrait a été modifié. Consultez donc la dernière annonce de Microsoft pour connaître les échéances en vigueur, plutôt que de vous fier à une date lue dans un article de blog, celui-ci compris. Le travail d'inventaire, lui, reste le même quelle que soit la date.
Pourquoi ce chantier est encore ouvert
L'authentification Basic a déjà été désactivée dans Exchange Online pour Exchange ActiveSync, POP, IMAP, Remote PowerShell, EWS, OAB, Autodiscover et les clients Outlook. SMTP AUTH a été laissé en place là où il était utilisé, et désactivé dans les tenants où il ne l'était pas.
Plus de 97 % des attaques par credential stuffing et plus de 99 % des attaques par password spray utilisent l'authentification héritée (legacy authentication), selon l'analyse de Microsoft dans son guide sur le blocage de la legacy authentication.
SMTP AUTH est utilisé par les clients POP3 et IMAP4 qui doivent aussi envoyer du courrier, ainsi que par les applications, serveurs de rapports et appareils multifonctions qui génèrent des mails.
Retrouver ce qui l'utilise encore
Il est possible que vous ne trouviez rien. Si les security defaults sont activés, SMTP AUTH est déjà désactivé dans Exchange Online. Il l'est aussi pour les organisations créées après janvier 2020, sauf si quelqu'un l'a activé boîte par boîte.
Sinon, commencez par les journaux de connexion. Dans le Microsoft Entra admin center, ouvrez Entra ID > Monitoring & health > Sign-in logs, ajoutez la colonne Client App et filtrez sur les protocoles d'authentification héritée. Répétez l'opération dans l'onglet User sign-ins (non-interactive), car les appareils se connectent rarement de manière interactive. Le workbook Sign-ins using legacy authentication aide au tri.
Examinez ensuite les boîtes aux lettres. Les paramètres par boîte prennent le pas sur le paramètre global de l'organisation : listez donc celles où SMTP AUTH est explicitement activé :
$Users = Get-CASMailbox -ResultSize unlimited
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $false}Une valeur vide signifie que la boîte suit le paramètre de l'organisation. Vérifiez-le avec Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled. Passez ensuite en revue la page « scan vers e-mail » des imprimantes, les paramètres de notification de l'ERP, les outils de supervision et de sauvegarde, ainsi que tout script planifié qui envoie un rapport.
Associez chaque occurrence à un responsable et notez l'adresse d'envoi, le port, si un tiers héberge l'émetteur, et si les destinataires sont internes ou externes. Ces informations sont indispensables pour choisir la solution de remplacement.
Vers quoi migrer chaque émetteur
La bonne cible dépend de ce que l'émetteur sait faire, de l'endroit où il s'exécute et de ses destinataires.
| Émetteur | Migrer vers | Hébergé par un tiers ? | Remarques |
|---|---|---|---|
| Application compatible OAuth | Client SMTP submission avec OAuth | Pris en charge | Port 587, TLS 1.2 ou 1.3, boîte aux lettres sous licence |
| Notifications internes uniquement | High Volume Email | Pris en charge | Port 587, compte HVE |
| Destinataires internes, authentification impossible | Direct Send | Pris en charge | Port 25, mettre à jour le SPF |
| Destinataires internes et externes | Azure Communication Services Email | Non couvert par le comparatif de Microsoft | Recommandation de Microsoft pour ce cas |
| Appareil sans OAuth, sur votre réseau | Relais SMTP via un connecteur | Non pris en charge | Port 25, certificat ou IP fixe |
| Script ou code développé en interne | OAuth 2.0 ou l'API Graph | Votre code | Modifier le code |
Microsoft recommande OAuth pour le client SMTP submission, et préconise HVE pour le courrier strictement interne et Azure Communication Services Email pour le courrier interne et externe. Si vous disposez d'un serveur de messagerie on-premises, vous pouvez aussi relayer via celui-ci, soit avec une authentification Basic auprès de ce serveur, soit avec un relais anonyme (et non un open relay).
Vérifiez d'abord les volumes. L'envoi via OAuth est limité à 10 000 destinataires par jour et à 30 messages par minute. Le relais SMTP n'est pas soumis à ces limites, même s'il a ses propres limites raisonnables, et HVE n'impose aucune limite de débit en destinataires ni en messages pour le courrier interne.
Imprimantes et scanners
Vérifiez d'abord le firmware : une mise à jour du constructeur peut ajouter la prise en charge d'OAuth. Dans le cas contraire, le relais SMTP via connecteur est la réponse habituelle. Il ne nécessite aucune boîte aux lettres sous licence, s'authentifie par certificat TLS (recommandé) ou par une IP publique fixe non partagée avec une autre organisation, et utilise le port 25 vers votre endpoint MX.
Le relais n'enregistre pas les messages dans les Éléments envoyés et ne contourne pas l'anti-spam : un courrier suspect peut donc être filtré. Microsoft recommande d'ajouter une entrée dans l'enregistrement SPF, et vous pouvez contrôler cet enregistrement avec notre vérificateur DMARC et SPF. Un appareil qui utilise le port 465 par défaut ne prend pas en charge les versions de TLS exigées par le client SMTP submission, et un appareil sans TLS 1.2 ne peut pas l'utiliser du tout.
Systèmes ERP et autres applications
Les applications métier comme un ERP sont les plus difficiles, car l'éditeur maîtrise le code d'envoi des mails. Demandez si le produit prend en charge OAuth 2.0 pour SMTP ou l'API Graph. Sinon, le relais par connecteur reste la solution de repli, à condition que l'application s'exécute sur votre propre réseau.
Si l'éditeur l'héberge, le relais est exclu : dans le tableau de Microsoft, le relais SMTP est la seule méthode qui ne prend pas en charge les émetteurs hébergés par un tiers. L'éditeur peut recourir au client SMTP submission avec OAuth, à HVE si le courrier ne part que vers des destinataires internes, ou à Azure Communication Services Email. Direct Send fonctionne aussi pour les émetteurs hébergés, mais il n'est pas authentifié : mettez donc à jour votre enregistrement SPF pour autoriser l'éditeur à envoyer au nom de votre domaine.
Si l'application envoie avec une adresse différente de la boîte aux lettres utilisée pour la connexion, accordez l'autorisation Send As. Sans elle, les messages sont rejetés avec l'erreur 5.7.60 SMTP; Client doesn't have permissions to send as this sender.
Scripts
Pour les scripts que vous maîtrisez, Microsoft cite l'API Graph comme alternative pour l'envoi authentifié, ou vous pouvez implémenter OAuth 2.0 sur les endpoints IMAP, POP ou SMTP.
Par où commencer
- Extrayez les connexions legacy des journaux Entra, interactives et non interactives, et listez les boîtes aux lettres dont
SmtpClientAuthenticationDisabledvaut$false. - Désignez un responsable pour chaque émetteur et consignez ses destinataires (internes ou externes), son port, sa prise en charge de TLS et le fait qu'un tiers l'héberge ou non.
- Choisissez une cible dans le tableau ci-dessus, testez un appareil de chaque type et ne basculez chacun qu'après l'envoi réussi d'un message de test.
- Après la migration, exécutez
Set-TransportConfig -SmtpClientAuthenticationDisabled $true. Une boîte aux lettres encore à$falseprend le dessus : définissez donc chacune à$null(suivre l'organisation) ou à$trueavecSet-CASMailbox. Relancez le filtre-eq $falsepour prouver qu'il n'en reste aucune, et confirmez la valeur de l'organisation avecGet-TransportConfig. - Créez une politique d'accès conditionnel (Conditional Access) qui bloque l'authentification héritée, en mode Report-only dans un premier temps, avec au moins un compte de secours exclu.
Si l'inventaire révèle plus d'éléments que vous ne pouvez en migrer dans les délais, notre équipe de conseil peut vous accompagner dans l'évaluation et le plan de bascule.
