Configurer Exchange 2019 pour le relais SMTP anonyme

Configurer Exchange 2019 pour le relais SMTP anonyme

Cet article fournit des conseils pour configurer Exchange Server 2019 en tant que relais anonyme. Nous documentons comment configurer Exchange Server 2019 en tant que relais anonyme au sein de votre propre réseau. Pour y parvenir nous utilisons vos plages de réseau interne pour limiter qui peut relayer les e-mails.

Ce que fait le relais anonyme

Le relais anonyme est une exigence courante pour ceux souhaitent autoriser des services ou applications à envoyer des emails. Citons notamment les appareils multifonctions tels que les imprimantes et les applications logicielles. Les organisations utilisant des déploiements hybrides peuvent également bénéficier de la possibilité de relayer anonymement des emails. Pour cela elles utilisent des serveurs Exchange 2019 au lieu d’un serveur SMTP générique. Les prérequis documentés de Microsoft pour les déploiements hybrides d’Exchange incluent la prise en charge d’Exchange Server 2019. Cela renforce encore les arguments en faveur de l’utilisation des serveurs Exchange 2019.

Cadre de test

Le laboratoire Exchange 2019 comprend un contrôleur de domaine, un serveur Exchange 2019 et une machine cliente Windows 10. Ces scénarios ne sont PAS destinés à être connectés à Internet, mais à reproduire les étapes décrites dans cet article.

La configuration

Notre laboratoire contient trois machines :

Relais interne ou relais ouvert ?

Un relais interne est un serveur SMTP qui relaye vers une destination les emails provenant d’une source interne. Cette destination peut être votre organisation Exchange sur site, un tenant Office 365 ou, des domaines de messagerie externes.

Un relais ouvert est un serveur de messagerie mal configuré, qui autorise des connexions de n’importe pour n’importe quel domaine. Les relais ouverts ont tendance à être trouvés par les pourvoyeurs de spam. Ils prennent le contrôle du système pour envoyer de grandes quantités d’emails et finissent par être blacklistés.

Gestion du trafic SMTP

Lorsque nous configurons un relais anonyme, nous devons savoir d’où proviennent les requêtes SMTP pour une des deux raisons:

• Parce que nous avons désigné des sous-réseaux de services autorisés, tels que des serveurs, des imprimantes, des applications, etc.
• Parce que nous connaissons les adresses IP individuelles des machines qui nécessitent un relais SMTP.

Il est évidemment plus facile de travailler avec des sous-réseaux clairement définis. Mais nous pouvons également utiliser une liste d’adresses IP. Nous couvrirons les deux scénarios plus loin.

Espace de noms

Les espaces de noms vous permettent d’assurer l’avenir d’un service et de le faire évoluer ultérieurement. Nous pouvons concevoir un espace de nom SMTP appelé relay.company.com comme un espace de nom à charge équilibrée, en utilisant :

• soit un alias DNS,
• soit un équilibreur de charge.

Nous pouvons également ajouter un composant géographique. Utilisons relay-sea.company.com ou relay-lhr.company.com, avec dans ce cas les codes des aéroports de Seattle et de Londres Heathrow.

Pourquoi se soucier de créer un espace de noms si nous n’avons qu’une seule machine ? Ainsi le service que nous créons est indépendant du nom de la machine.

Considérons un scénario de succursale à Seattle avec un serveur Exchange 2013 à mettre à niveau vers Exchange 2019. Si nos imprimantes et nos applications ont été configurées pour utiliser EXSEA2013 comme relais SMTP, par opposition à SMTPSEA.company.com, nous devons reconfigurer de nombreux points configurés pour pointer vers un serveur, par opposition à l’échange de l’ancien serveur contre un nouveau derrière un espace de nom.

Dans notre laboratoire, nous créons d’abord un enregistrement CNAME : mail.practical365lab.com pointant vers notre serveur Exchange 2019, LAB2019EX1 (Figure 1), en utilisant la console DNS sur Lab2019DC1 :

Exchange 2019

L’architecture d’Exchange Server 2019 déploie les serveurs Exchange comme un seul bloc de construction, contenant des rôles frontaux et dorsaux. Les services Front End Transport et Transport sont colocalisés sur le même serveur. Lorsque vous installez un nouveau serveur Exchange 2019, plusieurs connecteurs de réception sont créés. Et notamment le connecteur de réception par défaut pour permettre à Exchange de recevoir des e-mails depuis Internet. Nous examinerons brièvement les détails des connecteurs de réception par défaut. Puis nous les ignorerons lorsque nous créerons un connecteur de relais anonyme dédié.

Commençons par examiner les connecteurs par défaut sur notre serveur Exchange 2019 (LAB2019EX1) via PowerShell et l’interface graphique d’administration d’Exchange.

Get-ReceiveConnector
 
[PS] C:\>Get-ReceiveConnector
 
Identity                                      Bindings                  Enabled
--------                                      --------                  -------
LAB2019EX1\Default LAB2019EX1                 {0.0.0.0:2525, [::]:2525} True
LAB2019EX1\Client Proxy LAB2019EX1            {[::]:465, 0.0.0.0:465}   True
LAB2019EX1\Default Frontend LAB2019EX1        {[::]:25, 0.0.0.0:25}     True
LAB2019EX1\Outbound Proxy Frontend LAB2019EX1 {[::]:717, 0.0.0.0:717}   True
LAB2019EX1\Client Frontend LAB2019EX1         {[::]:587, 0.0.0.0:587}   True
 
 
[PS] C:\>

Dans l’Exchange Admin Center, naviguez vers le flux de courrier et ensuite vers les connecteurs de réception. Sélectionnez le serveur sur lequel vous souhaitez afficher les connecteurs de réception :

Connecteur de réception dédié

Nous allons créer un connecteur de réception dédié pour le relais anonyme à partir d’adresses IP internes spécifiques. Il s’agit d’une meilleure idée que de modifier le connecteur de réception par défaut configuré pour recevoir des emails d’Internet. Garder les connecteurs de réception par défaut permet d’éviter que les serveurs ne deviennent des relais ouverts.

Dans notre laboratoire, notre plage d’adresses internes est 192.168.12.0/24. Mais nous ne voulons pas configurer notre connecteur pour qu’il accepte les connexions de tout le sous-réseau. Pour les besoins de l’article, nous supposerons que AB2019Client avec l’adresse IP 192.168.12.5 est notre serveur d’application/imprimante multifonction. Pour les besoins de la démonstration, nous supposons que la plage 192.168.20.0/24 est configurée pour les imprimantes nécessitant des services de relais SMTP. Nous configurons notre connecteur en conséquence. Cela nous permet de démontrer l’ajout d’adresses IP sélectionnées ainsi que de sous-réseaux entiers pour sécuriser notre connecteur.

Exécutez la commande PowerShell suivante pour créer et configurer le connecteur :

#Create a new Front End receive connector called "P365 Anonymous Relay"
New-ReceiveConnector -Name "P365 Anonymous Relay" `
-TransportRole FrontendTransport -Custom -Bindings 0.0.0.0:25 `
-RemoteIpRanges 192.168.12.5, 192.168.20.0/24
 
#Configure "P365 Anonymous Relay" to be used anonymously
Set-ReceiveConnector "P365 Anonymous Relay" -PermissionGroups AnonymousUsers
Get-ReceiveConnector "P365 Anonymous Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" `
-ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"
 
#Configure "P365 Anonymous Relay" as externally secured
Set-ReceiveConnector "P365 Anonymous Relay" -AuthMechanism ExternalAuthoritative `
-PermissionGroups ExchangeServers

Voici la sortie PowerShell pour les commandes ci-dessus :

[PS] C:\>#Create a new Front End receive connector called "P365 Anonymous Relay"
[PS] C:\>New-ReceiveConnector -Name "P365 Anonymous Relay" `
>> -TransportRole FrontendTransport -Custom -Bindings 0.0.0.0:25 `
>> -RemoteIpRanges 192.168.12.5, 192.168.20.0/24
 
Identity                        Bindings     Enabled
--------                        --------     -------
LAB2019EX1\P365 Anonymous Relay {0.0.0.0:25} True
 
 
[PS] C:\>
[PS] C:\>#Configure "P365 Anonymous Relay" to be used anonymously
[PS] C:\>Set-ReceiveConnector "P365 Anonymous Relay" -PermissionGroups AnonymousUsers
[PS] C:\>Get-ReceiveConnector "P365 Anonymous Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" `
>> -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"
 
Identity             User                 Deny  Inherited
--------             ----                 ----  ---------
LAB2019EX1\P365 A... NT AUTHORITY\ANON... False False
 
 
[PS] C:\>
[PS] C:\>#Configure "P365 Anonymous Relay" as externally secured
[PS] C:\>Set-ReceiveConnector "P365 Anonymous Relay" -AuthMechanism ExternalAuthoritative `
>> -PermissionGroups ExchangeServers
[PS] C:\>

Nous pouvons accéder au connecteur via l’Administration d’Exchange, en naviguant vers le flux email puis vers les connecteurs de réception :

Double-cliquez sur le nouveau connecteur, cliquez sur sécurité pour valider et ensuite sur scoping pour visualiser la sécurité :

Et les paramètres du réseau :

Comment savons-nous que ça a marché ?

Ci-dessous nous voyons un test de notre serveur d’application Lab2019Client utilisant Send-MailMessage pour tester notre connecteur depuis la machine LAB2019Client. Avant de créer le connecteur, nous n’étions pas en mesure de relayer les emails de manière anonyme, après avoir créé le connecteur, le test réussit.

Test à l’aide de PowerShell

La figure 6 ci-dessous montre le résultat de nos tests en utilisant la cmdlet Send-MailMessage de PowerShell :

Send-MailMessage -SmtpServer mail.practical365lab.com `
-From ‘administrator@practical365lab.com’ -To ‘nicolasblank@gmail.com’ ‘
-Subject ‘Test Email’ -Port 25

Test à l’aide de Telnet

Test à l’aide de Telnet – avant de configurer le connecteur de réception illustré ci-dessous à la figure 7. Nous nous attendons à ce que notre test telnet tentant de relayer le courrier via le serveur Exchange 2019 échoue, ce qui est le cas.

Test à l’aide de Telnet – après avoir configuré le connecteur de réception illustré ci-dessous à la Figure 8. Ce test se termine avec succès avec le message de courrier reçu par Exchange 2019 et mis en file d’attente pour la livraison.

Entretien permanent

Puisque nous avons créé un alias DNS pour mail.practical365lab.com, nous pouvons remplacer le serveur Exchange à tout moment par une version plus récente. Ou bien nous pouvons configurer plusieurs serveurs Exchange derrière une adresse IP virtuelle hébergée par un équilibreur de charge.

Comme nous avons utilisé PowerShell pour créer le connecteur, nous sommes en mesure de répliquer la logique de création sur autant de serveurs que nécessaire.