I. Présentation

Depuis janvier 2023, l'authentification basique a été supprimée pour les protocoles POP, IMAP et Active Sync dans Exchange Online. Pour l'envoi des e-mails, le protocole SMTP utilisant l'authentification basique est toujours en vigueur.

Cependant, Microsoft a annoncé la fin de l'authentification basique pour SMTP, prévue pour septembre 2025. Cette modification impactera smtp.office365.com et smtp-legacy.office365.com.

II. Authentification basique vs authentification moderne

A. Fonctionnement authentification basique

L’authentification basique (Basic Authentication en anglais) est une méthode permettant de s’authentifier à un service en envoyant son nom d’utilisateur et son mot de passe. Pour garantir la sécurité des données échangées, le chiffrement TLS est couramment utilisé pour assurer la confidentialité des communications.

L'authentification basique est parfois appelée "proxy authentication" car le client de messagerie envoie le nom d’utilisateur et le mot de passe à Exchange Online, qui les transmet (ou "proxy") ensuite au fournisseur d'identités faisant autorité.

Dans un fonctionnement classique, l’authentification basique avec Exchange Online fonctionne comme suit :

1. Le client de messagerie/application envoie le nom d'utilisateur et le mot de passe à Exchange Online.
2. Exchange Online envoie le nom d'utilisateur et le mot de passe au fournisseur d’identités Microsoft Entra ID.
3. Microsoft Entra ID renvoie un ticket utilisateur à Exchange Online et l'utilisateur est authentifié.

Lorsque l'authentification basique est bloquée, elle est bloquée à l‘étape 1.

B. Risques de sécurité de l’authentification basique

L'utilisation de l'authentification basique implique l'envoi des identifiants à chaque requête, ce qui la rend vulnérable aux attaques de type man-in-the-middle. Afin de pouvoir être utilisés à chaque requête, ces identifiants sont donc souvent stockés sur le périphérique.

De plus, l’authentification basique complique, voire rend impossible l'application de l'authentification multifacteur (MFA) selon les cas.

L'authentification basique est donc fréquemment utilisée par les attaquants comme vecteur d'attaque pour contourner certaines politiques de sécurité, notamment pour réaliser des attaques de type brute force sans être bloqués par le MFA.

SMTP est aujourd’hui le dernier protocole Exchange Online qui utilise l’authentification basique. C'est pourquoi Microsoft prévoit de désactiver l’authentification basique pour SMTP en faveur de l’authentification moderne.

C. Authentification moderne

L'authentification moderne est un terme générique défini à l'origine par Microsoft, mais de nombreuses autres entreprises l'utilisent désormais pour décrire les éléments suivants :

- Méthodes d'authentification : vérifier que quelqu'un ou quelque chose est bien ce qu'il prétend être. Notamment via l’authentification multifacteur (MFA), l’authentification par carte à puce, authentification par certificat. OpenIDConnect est la norme la plus largement utilisée pour l’authentification.

- Méthodes d'autorisation : processus de sécurité qui détermine le niveau d'accès d'un utilisateur ou d'un service. OAuth2 est la norme utilisée pour l’autorisation.

- Stratégies d'accès conditionnel : stratégies qui définissent les conditions dans lesquelles certaines mesures supplémentaires doivent être prises pour accéder à une ressource.

À noter qu’il existe d’autres normes qui permettent l’authentification et/ou l’autorisation comme SAML, WS-FED.

III. Agenda étapes avant la désactivation

Microsoft a prévu un planning avant la désactivation afin de laisser le temps aux entreprises de réaliser les changements.

- Septembre 2024 : Microsoft met à jour les rapports pour indiquer si l'envoi SMTP a été réalisé via OAuth ou via l'authentification basique.

Le rapport qui sera mis à jour par Microsoft est celui présent dans le centre d'administration Exchange Online > "Rapports" > "Flux de courrier" > "Rapport sur les clients utilisant l’authentification SMTP".

- Janvier 2025 : les tenants utilisant encore l'authentification basique pour SMTP recevront une alerte dans le Centre de messages Microsoft 365.

- Août 2025 : 30 jours avant la désactivation de l'authentification basique pour SMTP, nouvelle alerte dans le Centre de messages Microsoft 365.

- Septembre 2025 : désactivation définitive de l'authentification basique pour SMTP.

IV. Impacts de la fin de l’authentification basique pour SMTP

Une fois que l'authentification basique est désactivée de manière permanente, tous les clients ou applications qui se connectent en utilisant l'authentification basique pour SMTP recevront cette réponse :

550 5.7.30 Basic authentication is not supported for Client Submission.

Sauf cas très précis, les client Outlook (bureau, web ou mobile) n’utilisent pas le SMTP, ils utilisent MAPI over HTTP. De ce fait, vos utilisateurs ne sont pas impactés par ce changement.

Cependant, il est possible que vous utilisiez SMTP pour différents usages :

• Utilisation d’un outil de messagerie qui ne supporte pas MAPI over HTTP
• Envoi d’e-mail depuis une application, une imprimante multi-fonction, etc.
• Des scripts (PowerShell, Python, etc.)

Dans ces cas-là, si vous utilisez un compte Exchange Online avec authentification basique, vous êtes probablement à risque et vous devez agir avec l’un des cas suivants.

1. Si votre application prend en charge OAuth, reconfigurez-la en conséquence.

2. Si votre application ne prend pas en charge OAuth, envisagez une des solutions suivantes (liste non exhaustive) :

- Option 2 ou 3 de la documentation Microsoft sur la configuration des applications et multi-fonction.
- High Volume Email for Microsoft 365 (pour les e-mails internes uniquement).
- Azure Communication Services Email SMTP (pour les e-mails internes et externes).
- Serveur de messagerie tiers (Microsoft Exchange, hMailServer ou équivalent sur les autres OS).
- Solutions SaaS d'envoi d'e-mails (Brevo, Mailjet, SMTP2Go, PostMark, etc.).

The post Microsoft 365 – Exchange Online : fin de vie pour l’authentification basique SMTP first appeared on IT-Connect.

Vous voulez envoyer des emails chiffrés de bout en bout avec votre client mail favori, mais sans vous prendre la tête ? J’ai ce qu’il vous faut les amis : le projet open source ProtonMail Bridge pour Docker de mon gars sûr DaTux, un fidèle lecteur de Korben.info que je croise souvent sur mon live Twitch.

Ce mec a passé plus de temps à rédiger le README.md de son projet qu’à le coder, mais le résultat est là : une version dockerisée de l’interface en ligne de commande de ProtonMail Bridge qui crée un serveur SMTP local. Comme ça, vos autres conteneurs Docker peuvent envoyer des mails via votre compte ProtonMail. La classe, non ?

Bon par contre, petit bémol : pour l’instant, il faut un compte payant (Mail Plus, Proton Unlimited ou Proton Business) pour se connecter. Ça marchera pas avec les comptes gratuits. Mais vu le niveau de confidentialité et de sécurité que ça apporte à vos échanges d’emails pro, ça les vaut !

Pour commencer, récupérez la dernière image Docker avec :

docker pull ghcr.io/videocurio/proton-mail-bridge:latest

Ou la version allégée basée sur Alpine Linux :

docker pull ghcr.io/videocurio/proton-mail-bridge-alpine:latest

Ensuite, lancez le conteneur en exposant les ports TCP 12025 pour SMTP et 12143 pour IMAP sur votre interface réseau locale.

docker run -d --name=protonmail_bridge -v /path/to/your/volume/storage:/root -p 127.0.0.1:12025:25/tcp -p 127.0.0.1:12143:143/tcp --network network20 --restart=unless-stopped ghcr.io/videocurio/proton-mail-bridge:latest

N’oubliez pas de fournir un volume pour la persistance des données (mkdir /path/to/your/volume/storage).

Maintenant, ouvrez un terminal dans le conteneur en cours d’exécution et utilisez l’interface de commande interactive de ProtonMail Bridge :

docker exec -it protonmail_bridge /bin/bash

À l’intérieur, killez d’abord l’instance de bridge par défaut car une seule peut tourner à la fois :

pkill bridge

Puis connectez-vous à votre compte ProtonMail (rappel : faut un compte payant) :

/app/bridge --cli

Suivez les instructions à l’écran, renseignez votre nom d’utilisateur, mot de passe et code 2FA. Une synchro de votre compte va commencer. Prenez un café en attendant ! Si vous utilisez plusieurs domaines ou adresses email, passez en mode « split » qui va vous permettre de définir des identifiants pour chaque adresse du compte.

Ensuite re-faite ceci pour resynchroniser encore un petit coup :

change mode 0

Quand c’est fini, tapez info pour récupérer les infos de connexion SMTP/IMAP générées par ProtonMail Bridge. Copiez bien l’username ET le mot de passe (différent de celui de votre compte ProtonMail !!). Vous pouvez maintenant configurer votre client mail favori avec ces identifiants, en précisant les ports SMTP 12025 et IMAP 12143 qu’on a exposés au lancement du conteneur Docker.

Et voilà, vous pouvez envoyer des emails chiffrés de bout en bout dans la plus grande des discrétion ! Évidemment, le destinataire devra aussi avoir un compte ProtonMail pour les déchiffrer de son côté.

Pour aller plus loin, j’vous conseille de jeter un œil au README hyper complet de DaTux, avec tous les détails d’install et d’utilisation. Il a même prévu une version optimisée pour tourner sur un serveur TrueNAS Scale, le bienheureux.

En soutien, n’hésitez pas à lui mettre une petite étoile sur son repo GitHub et à partager ce tuto autour de vous !

A la prochaine !