AuthMechanism 10 et AuthAs Internal : comment Exchange classe la remise dans l’en-tête

Lors de l’analyse de cas de spam, d’usurpation et de flux de messagerie dans des environnements Exchange, trois en-têtes apposés par Exchange à la réception sont déterminants :

X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthSource: EX01.example.com
X-MS-Exchange-Organization-AuthMechanism: 10

AuthAs indique sous quelle identité l’expéditeur s’est présenté au transport. AuthSource désigne le serveur qui a effectué l’évaluation. AuthMechanism documente le mécanisme par lequel l’authentification a été établie. Ensemble, ils déterminent si Exchange traite un message comme interne ou externe, et cette classification a des conséquences importantes.

Pourquoi cette classification est importante

AuthAs connaît en pratique deux valeurs : Internal et Anonymous. Un message classé comme Internal est traité différemment d’un e-mail externe :

• Les règles de flux de messagerie ayant la condition « expéditeur en dehors de l’organisation » ne s’appliquent pas.
• Le message peut être distribué à des groupes de distribution et à des boîtes aux lettres qui exigent des expéditeurs authentifiés (RequireSenderAuthenticationEnabled).
• Les contrôles antispam et anti-usurpation sont moins stricts ou ne sont pas effectués ; dans les environnements hybrides, l’avertissement externe n’est pas ajouté et Outlook n’affiche aucune indication « Externe ».
• Le nom d’affichage est résolu depuis le carnet d’adresses, et l’e-mail apparaît aux destinataires comme un message interne.

C’est précisément pourquoi la question « AuthAs Internal ou Anonymous ? » doit figurer au début de toute analyse d’en-tête : elle permet de déterminer pourquoi un e-mail d’usurpation manifeste a franchi le filtre antispam ou pourquoi une règle de flux de messagerie ne s’est jamais déclenchée.

Les valeurs AuthMechanism

Microsoft ne documente pas entièrement et publiquement le codage de AuthMechanism. Deux valeurs sont pertinentes et bien documentées pour le dépannage :

D’autres valeurs apparaissent dans les en-têtes, mais sans référence officielle. En pratique, la distinction suffit : 04 signifie une véritable authentification Exchange, 10 signifie une relation de confiance établie par la configuration du connecteur.

Ce que signifie réellement Externally Secured

L’option ExternalAuthoritative sur un Receive Connector indique à Exchange : quelqu’un d’autre assure la sécurité de cette connexion, par exemple un pare-feu, un segment réseau dédié ou IPsec. Exchange ne vérifie alors plus rien et traite chaque remise via ce connecteur comme authentifiée et interne, y compris avec le droit d’utiliser n’importe quelle adresse d’expéditeur interne.

Cette option est prévue pour quelques scénarios seulement, par exemple un serveur d’applications entièrement digne de confiance dans son propre centre de données. Elle devient problématique lorsque le connecteur pointe vers une passerelle de messagerie en amont ou un filtre antispam dans la DMZ, par lequel transite également le courrier Internet. Après remise, chaque e-mail externe porte alors :

X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 10

Conséquences : les e-mails externes sont considérés comme internes, les règles de flux de messagerie pour les expéditeurs externes ne s’appliquent pas, la protection contre l’usurpation pour votre propre domaine est inefficace, et toute personne pouvant atteindre la passerelle peut remettre des messages avec des adresses d’expéditeur internes à des destinataires qui exigent en principe des expéditeurs authentifiés.

Trouver les connecteurs concernés

L’Exchange Management Shell permet d’afficher les Receive Connectors configurés avec ExternalAuthoritative :

Get-ReceiveConnector | Where-Object {
  $_.AuthMechanism -match "ExternalAuthoritative"
} | Format-Table Identity, RemoteIPRanges, AuthMechanism, PermissionGroups

Pour chaque résultat, vérifiez quelles RemoteIPRanges sont renseignées et si les systèmes concernés ont réellement besoin de cette relation de confiance. Une passerelle qui doit uniquement relayer des e-mails n’en a pas besoin.

L’alternative pour les scénarios de relais

Si un système doit uniquement relayer anonymement via Exchange (imprimante, application, supervision), un connecteur de relais anonyme est la solution plus propre : remise anonyme avec le droit de distribuer à n’importe quel destinataire, mais sans la classification Internal.

New-ReceiveConnector -Name "Anonymous Relay" -TransportRole FrontendTransport `
  -RemoteIPRanges 192.0.2.10 -Bindings 0.0.0.0:25 -Usage Custom -PermissionGroups AnonymousUsers

Get-ReceiveConnector "EX01\Anonymous Relay" | Add-ADPermission `
  -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

Les e-mails transmis via ce connecteur restent AuthAs: Anonymous, passent par les contrôles habituels et ne peuvent pas usurper des expéditeurs internes. ExternalAuthoritative doit rester réservé aux systèmes auxquels vous souhaitez délibérément accorder le droit d’utiliser des adresses d’expéditeur internes.

Lire les en-têtes dans leur contexte

Pour déterminer le plus rapidement possible si un message concret a été classé comme interne ou externe et par quel chemin il est arrivé, consultez l’en-tête complet : AuthAs, AuthMechanism et AuthSource, ainsi que la chaîne Received. L’analyseur d’en-têtes de messagerie sur ce site évalue directement ces champs dans le navigateur et met en évidence la classification hybride dans le chemin de distribution ; l’en-tête ne quitte pas le navigateur.

L’article Interne ou externe ? Classer les e-mails Exchange hybrides dans l’en-tête explique comment la classification est préservée entre Exchange Online et OnPrem dans les environnements hybrides et comment identifier une attribution incorrecte.