FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Microsoft Exchange Server 2013 : fin du support le 11 avril 2023

23 janvier 2023 à 09:00

Microsoft a mis en ligne un nouvel article pour avertir ses clients que le support d'Exchange Server 2013 prenait fin dans moins de 3 mois : le 11 avril 2023 pour être précis. Voici ce qu'il faut savoir.

À compter du 11 avril 2023, Microsoft Exchange Server 2013 ne sera plus sous support Microsoft. Même si cette date est connue depuis longtemps, il est important d'émettre une piqûre de rappel à ce sujet, et d'informer un maximum de personnes de cette échéance.

À compter de cette date, Microsoft ne réalisera plus de support technique pour Exchange Server 2013. Par ailleurs, cette version d'Exchange Server ne recevra plus de mises à jour, que ce soit pour corriger des failles de sécurité ou des bugs fonctionnels. Autrement dit, à partir du 11 avril 2023, si vous continuez d'utiliser Exchange Server 2013, ce sera à vos risques et périls. Ces derniers mois, Microsoft Exchange a été régulièrement concernée par des failles de sécurité critiques, donc le risque n'est pas neutre.

Afin de continuer à utiliser Microsoft Exchange Server, vous devez migrer vers Exchange Server 2019 ou passer sur Exchange Online, la version Cloud rattachée aux offres Microsoft 365. Pour ce second cas, Microsoft met à disposition des outils et ressources pour faciliter la migration vers le Cloud via FastTrack. Sur le site dédié à ce service, Microsoft précise : "FastTrack aide les clients à déployer des solutions cloud Microsoft. Les clients titulaires d’abonnements éligibles à Microsoft 365, Azure ou Dynamics 365 peuvent utiliser FastTrack sans coût supplémentaire pendant toute la durée de leurs abonnements.".

Même si ce n'est pas écrit noir sur blanc, Microsoft incite tout de même ses clients à migrer vers Exchange Online plutôt que sur Exchange Server 2019. J'en profite pour rappeler qu'Exchange Server 2019 sera remplacé par une autre version d'Exchange Server, mais ce ne sera pas avant 2025.

Tout est détaillé sur le site de Microsoft, sur cette page : Exchange Server 2013 End of Support Coming Soon

L'article Microsoft Exchange Server 2013 : fin du support le 11 avril 2023 est disponible sur IT-Connect : IT-Connect.

IIS and Exchange Server security with Windows Extended Protection (WEP)

18 janvier 2023 à 14:15

A little-known extension helps to increase the security of Windows Authentication to prevent credential relay or "man in the middle" attacks in Exchange Server and Internet Information Server (IIS). Microsoft is using Windows Extended Protection with modern security updates to enhance the built-in authentication capabilities found in Windows Server.

The post IIS and Exchange Server security with Windows Extended Protection (WEP) first appeared on 4sysops.

La dernière mise à jour d’Exchange Server vous protège du code PowerShell malveillant

12 janvier 2023 à 16:35

Au sein du Patch Tuesday de janvier 2023 mis en ligne par Microsoft, il y a des correctifs de sécurité à destination des serveurs de messagerie Microsoft Exchange Server. Cette mise à jour renforce la sécurité d'Exchange Server en lui permettant de mieux bloquer les charges PowerShell malveillantes.

La dernière mise à jour de sécurité à destination d'Exchange Server 2013, 2016 et 2019 permet aux entreprises de se protéger contre plusieurs failles de sécurité importantes, qui permettent à un attaquant d'élever ses privilèges sur le serveur de messagerie compromis. En complément de

Sur son site techcommunity.microsoft.com, l'entreprise américaine évoque également une nouveauté pour Exchange Server orientée sécurité, qui concerne PowerShell et le processus de sérialisation. Microsoft explique que PowerShell s'appuie sur la sérialisation pour transférer des objets entre des sessions, et qu'il y a cette volonté de protéger les serveurs Exchange contre les attaques qui cible les données sérialisées. Pour cela, Microsoft a ajouté la signature par certificat des payloads de sérialisation PowerShell (ce qui implique d'avoir un certification d'authentification sur chaque serveur Exchange).

Pour le moment, cette fonctionnalité doit être activée manuellement, mais il est fort probable qu'à l'avenir, Microsoft décide de l'activer au travers d'une mise à jour. La firme de Redmond a mis à disposition un script pour vérifier si votre environnement est prêt et pour activer la fonctionnalité, même s'il est possible de le faire manuellement. Tout est expliqué sur le site techcommunity.microsoft.com où l'on trouve également une FAQ.

Microsoft insiste sur le fait que cette fonctionnalité doit être activée uniquement après avoir mis à jour tous vos serveurs Exchange : "Cette fonctionnalité ne doit être activée qu'après avoir mis à jour tous vos serveurs Exchange avec la SU de janvier 2023 (ou plus récent). L'activation de cette fonctionnalité avant la mise à jour de tous les serveurs peut entraîner des échecs et des erreurs dans la gestion de votre organisation."

Exchange Server - PowerShell Certificate Signing - 2023

Pour rappel, les mises à jour d'Exchange Server de janvier 2023 sont disponibles pour les versions suivantes :

  • Exchange Server 2013 CU23 (dont le support prend fin le 11 avril 2023)
  • Exchange Server 2016 CU23
  • Exchange Server 2019 CU11 et CU12

Source

L'article La dernière mise à jour d’Exchange Server vous protège du code PowerShell malveillant est disponible sur IT-Connect : IT-Connect.

Plus de 60 000 serveurs Microsoft Exchange encore vulnérables à ProxyNotShell

4 janvier 2023 à 17:30

D'après les dernières statistiques, plus de 60 000 serveurs de messagerie Exchange restent vulnérables à la faille de sécurité CVE-2022-41082, associée aux exploits ProxyNotShell.

Pour rappel, l'exploit ProxyNotShell repose sur l'exploitation de deux failles de sécurité correspondantes aux références  CVE-2022-41082 et CVE-2022-41040. Ces vulnérabilités affectent les serveurs Exchange non patchés, que ce soit sur Exchange Server 2013, 2016 ou 2019. Grâce à de l'exécution de code à distance et à une élévation de privilèges, un attaquant peut compromettre le serveur de messagerie.

Même s'il y a de plus en plus de serveurs de messagerie protégés contre ProxyNotShell, le nombre de serveurs vulnérables reste encore très élevé à en croire les statistiques publiées par les chercheurs en sécurité de la Shadowserver Foundation.

A la mi-décembre, il y avait 83 946 serveurs Exchange vulnérables. Quelques semaines plus tard, au 2 janvier 2023 pour être précis, ce nombre est passé à 60 865 serveurs. C'est grâce à une analyse de l'en-tête HTTP qui est retournée lorsque l'on se connecte au webmail OWA que l'on peut déterminer si un serveur est vulnérable ou non.

Source : Shadowserver Foundation

Bien que ces vulnérabilités soient patchées depuis novembre 2022 de manière officielle grâce à des correctifs de Microsoft, on peut voir qu'il reste encore beaucoup d'entreprises vulnérables. Seul un serveur à jour avec les correctifs est totalement protégé car les mesures d'atténuations ont déjà pu être contournées, donc elles ne sont pas suffisantes.

Si vous n'avez pas encore fait le nécessaire, commencez l'année 2023 du bon pied en faisant le nécessaire avant que les cybercriminels du groupe ransomware Play en profitent.... Ce groupe, et surement d'autres groupes, utilisent cette opportunité pour faire de nouvelles victimes.

Dernièrement, ce sont les cybercriminels du groupe FIN7 qui ont mis au point une plateforme pour automatiser l'attaque contre les serveurs Exchange (et d'autres services). Pour cela, des millions de serveurs exposés sur Internet sont analysés. Plusieurs milliers de victimes ont déjà fait les frais de cette plateforme...

Source

L'article Plus de 60 000 serveurs Microsoft Exchange encore vulnérables à ProxyNotShell est disponible sur IT-Connect : IT-Connect.

Exchange Online – Passez au module EXO V3 de PowerShell avant juin 2023 !

21 décembre 2022 à 10:00

À partir de juin 2023, Microsoft va bloquer l'utilisation du protocole Remote PowerShell dans Exchange Online. Cela ne signifie pas qu'il ne sera plus possible d'interagir avec Exchange Online via PowerShell, mais qu'il falloir passer sur la dernière version du module : Exchange Online V3.

Au mois d'octobre dernier, Microsoft a fait part de sa décision d'éliminer l'authentification basique (Basic Authentication) afin de passer sur l'authentification moderne pour tout le monde et de renforcer la sécurité des comptes Microsoft 365. Ce changement s'applique aux différents types de connexions : MAPI, Exchange ActiveSync, IMAP, POP, RPC, Exchange Web Services (EWS), Offline Address Book ainsi que Remote PowerShell. C'est ce dernier point qui nous intéresse aujourd'hui.

Depuis plusieurs mois, Microsoft a mis en ligne le module Exchange Online V3 (EXO V3) et ce dernier s'appuie sur l'API REST. Plus sécurisée que les deux versions précédentes, cette nouvelle version présente l'avantage de supporter l'authentification moderne : elle va donc devenir incontournable puisque Microsoft va désactiver la Basic Authentication en juin 2023. Plus précisément, la désactivation va commencer à partir du 1er juin 2023 et elle sera effective sur tous les tenants au 1er juillet 2023.

Microsoft précise que vous devez installer le module EXO V3 et que vous devez établir la connexion avec le cmdlet Connect-ExchangeOnline à la place de New-PSSession. Par ailleurs, le paramètre "-UseRPSSession" ne doit plus être utilisé, et avant d'installer la nouvelle version, vous pouvez désactiver l'ancienne en exécutant avec les droits admin la commande ci-dessous :

Uninstall-Module ExchangeOnlineManagement

Vous pouvez retrouver l'annonce officielle avec tous les détails sur le site de Microsoft.

Si vous désirez apprendre à installer le module Exchange Online V3, vous pouvez lire ce tutoriel : PowerShell - Exchange Online V3. Ne vous laissez pas surprendre et mettez à jour vos scripts dès maintenant pour éviter d'avoir à traiter cette mise à jour en urgence à l'été prochain ! 😉

L'article Exchange Online – Passez au module EXO V3 de PowerShell avant juin 2023 ! est disponible sur IT-Connect : IT-Connect.

PowerShell : comment installer le module Exchange Online V3 ?

21 décembre 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons apprendre à installer le module PowerShell "Exchange Online V3" connu sous le nom "EXO V3", sur lequel Microsoft a travaillé pendant plusieurs mois. Il représente l'avenir et va devenir incontournable pour les personnes qui ont des scripts de configuration d'Exchange Online.

Pour refaire un peu l'historique, Microsoft a mis en ligne la V2 (2.0.3) de ce module le 21 septembre 2020. Ensuite, les versions preview se sont enchainées jusqu'à ce que sorte la version V2.0.5 le 11 mai 2021. Ensuite, il y a eu plusieurs preview de la version V2.0.6... Et finalement, cette version est sortie en version stable en tant que version 3.0.0.

A ce jour, c'est la version la plus évoluée, qui reprend les améliorations des versions précédentes comme la prise en charge l'authentification moderne avec ou sans MFA. Le module EXO V3 va plus loin car il supporte aussi l'authentification par certificat pour la partie "Sécurité et conformité" et interroge le Cloud via une API REST.

Ce module est capable de s'authentifier sur Exchange Online, Exchange Online Protection et Sécurité et Conformité.

Note : A partir de juin 2023, il ne sera plus possible d'utiliser le module Exchange Online V2 pour administrer Exchange Online car il ne supporte pas l'authentification moderne. D'où l'intérêt de passer sur la dernière version de ce module.

Pour en savoir plus sur tous les changements, vous pouvez consulter la documentation officielle de Microsoft :

II. Installer le module Exchange Online V3

Ce module est publié sur la PowerShell Gallery (voir ici) et on peut l'installer facilement via PowerShellGet avec la commande habituelle : Install-Module. Ceci nous donne la commande suivante :

Install-Module -Name ExchangeOnlineManagement

Pour cibler une version spécifique, par exemple la v3.0.0, on peut aussi la préciser de cette façon :

Install-Module -Name ExchangeOnlineManagement -RequiredVersion 3.0.0

L'installation s'effectue en quelques secondes, après avoir validé avec "A" puis "Entrée".

PowerShell - Install-Module ExchangeOnlineManagement V3

Une fois l'installation effectuée, on peut lister les commandes du module :

Get-Command -Module ExchangeOnlineManagement

Voici la liste :

PowerShell - Get-Command ExchangeOnlineManagement V3

Les nouvelles commandes, disponibles depuis la V2 de ce module, sont préfixées par "EXO". Voici quelques exemples :

  • Get-CASMailbox devient Get-EXOCASMailbox
  • Get-Mailbox devient Get-EXOMailbox
  • Get-MailboxFolderPermission devient Get-EXOMailboxFolderPermission
  • Get-MailboxFolderStatistics devient Get-EXOMailboxFolderStatistics
  • Get-MailboxPermission devient Get-EXOMailboxPermission
  • Etc...

Rassurez-vous, les anciennes commandes restent utilisables malgré tout. 😉

III. Se connecter à Exchange Online avec PowerShell

Le module est installé, donc nous allons pouvoir établir la connexion avec un environnement Office 365 via la commande Connect-ExchangeOnline.

Pour s'authentifier, il suffit de préciser son adresse e-mail (associé au compte qui a les droits) :

Connect-ExchangeOnline -UserPrincipalName [email protected]

Un navigateur va s'ouvrir, pour vous demander de vous connecter avec le mot de passe correspondant au compte mentionné. Ensuite, la connexion sera établie si votre compte n'est pas protégé par MFA. Dans le cas où il y a le MFA sur le compte, l'étape du MFA s'affiche, comme ceci :

PowerShell Exchange Online MFA

Après avoir validé ce second facteur d'authentification, la connexion est établie. Le message "Authentication complete. You can return to the application. Feel free to close this browser tab." s'affiche dans le navigateur. Vous pouvez fermer la fenêtre et commencer à exécuter des commandes comme celle-ci pour lister les boites aux lettres.

Get-EXOMailbox

Vous avez aussi la possibilité d'utiliser le mode d'authentification basé sur le périphérique, où un code sera donné, et il doit être saisit dans le navigateur à partir du compte déjà connecté à l'environnement cible. Dans ce cas, c'est cette commande qu'il faut utiliser :

Connect-ExchangeOnline -Device

Par la suite, lorsque vous avez terminé vos actions, vous pouvez fermer la session (ou les sessions) avec la commande suivante :

Disconnect-ExchangeOnline

Il sera nécessaire de valider pour déconnecter toutes les sessions :

PowerShell - Disconnect-ExchangeOnline

Pour supprimer la demande de confirmation :

Disconnect-ExchangeOnline -Confirm:$false

Dans le cas où l'on souhaite se connecter à la plateforme Sécurité et Conformité, le cmdlet Connect-IPPSession doit être utilisé.

IV. Conclusion

Vous êtes désormais en mesure d'installer le module Exchange Online Management "EXO V3" de PowerShell et de vous connecter à votre environnement Cloud, vous n'avez plus qu'à l'exploiter pour vos tâches d'administration !

L'article PowerShell : comment installer le module Exchange Online V3 ? est disponible sur IT-Connect : IT-Connect.

Ransomware Play : un nouvel exploit utilisé pour compromettre les serveurs Exchange !

21 décembre 2022 à 07:16

Actuellement, les cybercriminels du groupe ransomware Play effectuent des attaques informatiques à destination des entreprises équipées d'un serveur Microsoft Exchange. Pour compromettre le serveur, les pirates utilisent un nouvel exploit surnommé OWASSRF et lié à une faille de sécurité corrigée en novembre 2022 par Microsoft. Voici ce qu'il faut savoir.

L'entreprise CrowdStrike, spécialisée dans la cybersécurité, a mené des investigations sur des attaques réalisées par le groupe ransomware Play où le serveur Exchange a été compromis et utilisé pour accéder à l'infrastructure cible. Résultat, ils ont fait la découverte de cet exploit qu'ils ont appelés OWASSRF et qui consiste à exploiter la faille CVE-2022-41082 via Remote PowerShell. Il s'agit de la même vulnérabilité exploitée avec les attaques ProxyNotShell.

Avec ProxyNotShell, il fallait exploiter la vulnérabilité CVE-2022-41040 pour exploiter ensuite la CVE-2022-41082. Avec l'exploit OWASSRF, c'est différent comme l'explique CrowdStrike dans son rapport : "Dans chaque cas, CrowdStrike a examiné les journaux pertinents et a déterminé qu'il n'y avait aucune preuve d'exploitation de CVE-2022-41040 pour l'accès initial." - Il s'avère que les pirates ont exploités une autre vulnérabilité, plus récente, pour s'en prendre aux serveurs Exchange : la CVE-2022-41080 ! D'après Microsoft, il s'agit d'une faille critique mais qui n'était pas exploitée dans le cadre d'attaques. Sauf que désormais, c'est bien le cas.

Dans le cadre de leurs travaux, les chercheurs de chez CrowdStrike ont souhaité reproduire le même exploit PoC que les pirates du groupe ransomware Play. Toutefois, ils ont pu s'appuyer directement sur les informations publiées par Dray Agha, un chercheur chez Huntress Labs, qui a partagé des informations à ce sujet via Twitter. Au final, ce nouvel exploit serait utilisé par les pirates pour déployer des outils de prise en main à distance comme Plink et AnyDesk sur les serveurs compromis.

Se protéger de l'exploit OWASSRF

Pour se protéger contre ce nouvel exploit, vous devez mettre à jour votre serveur Microsoft Exchange : il doit disposer au minimum des mises à jour de novembre 2022 pour que la vulnérabilité CVE-2022-41080 soit patchée. En attendant de vous protéger, vous devez désactiver l'accès à OWA car c'est le point d'entré utilisé par les attaquants pour cibler les serveurs de messagerie. La faille de sécurité CVE-2022-41080 affecte les serveurs Exchange Server 2013, Exchange Server 2016 et Exchange Server 2019.

Lancé en juin 2022, le groupe Ransomware Play est particulièrement actif, alors n'attendez pas pour vous protéger ! D'ailleurs, il y a quelques jours, c'est le groupe hôtelier allemand H-Hotels qui a fait les frais de ces cybercriminels...

Source

L'article Ransomware Play : un nouvel exploit utilisé pour compromettre les serveurs Exchange ! est disponible sur IT-Connect : IT-Connect.

Cyberattaque de la supply chain de Gemini Exchange

16 décembre 2022 à 13:31
Par : UnderNews

Gemini Exchange, plateforme d’échange de cryptomonnaie, a été victime d’une cyberattaque compromettant plus de 5,7 millions d’adresses emails de clients.

The post Cyberattaque de la supply chain de Gemini Exchange first appeared on UnderNews.

Microsoft Exchange Server 2019 – Découverte et configuration de l’Autodiscover

30 novembre 2022 à 17:45

I. Présentation

Dans ce tutoriel, nous allons apprendre à configurer le service Autodiscover d'Exchange, correspondant au service de découverte automatique si l'on fait la traduction littéraire. Avant cela, nous verrons quel est l'intérêt de ce service indispensable ou presque.

Cet article s'inscrit dans une suite d'articles au sujet de l'installation et la configuration de Microsoft Exchange Server 2019 :

II. C'est quoi l'Autodiscover ?

Le mécanisme Autodiscover d'Exchange permet de faciliter la détection des paramètres de configuration pour se connecter à une boîte aux lettres hébergée sur un serveur de messagerie Exchange. Autrement dit, lorsqu'un utilisateur va ouvrir Outlook pour la première fois, ce dernier va solliciter le service de découverte automatique pour configurer votre boîte aux lettres sans qu'il soit nécessaire de renseigner les informations sur le serveur (serveur de courrier entrant, serveur de courrier sortant, numéros de ports, etc.).

Cette fonctionnalité incontournable est présente sur les serveurs de messagerie Exchange depuis Exchange Server 2007. L'Autodiscover est utilisable sur différents types d'appareils, que ce soit sur un ordinateur, un smartphone ou une tablette.

III. Configurer l'Autodiscover

Lorsque l'on a configuré les enregistrements DNS (article précédent), on a créé les enregistrements en respectant le modèle suivant :

Type d'enregistrement Nom DNS Valeur Priorité
A mail.domaine.fr Votre IP publique -
CNAME autodiscover.domaine.fr mail.domaine.fr -
MX @ mail.domaine.fr 10

Au final, avec l'ensemble des enregistrements, cela donnait ce résultat :

Exchange - Exemple zone DNS publique

Si l'on regarde cette liste, on constate la présence d'un enregistrement pour l'adresse "autodiscover.floiranburnel.fr" : ce n'est pas anodin. Cet enregistrement est nécessaire au bon fonctionnement de la découverte automatique, et le fait d'utiliser un enregistrement sous la forme "autodiscover.domaine.fr" permet de respecter les bonnes pratiques.

Au final, le point de terminaison de l'Autodiscover est un fichier XML qui devrait être accessible à l'adresse suivante :

https://autodiscover.domaine.fr/Autodiscover/Autodiscover.xml

Toutefois, au-delà de la création de l'enregistrement DNS, une configuration supplémentaire s'impose...

À l'aide d'Exchange Management Shell, exécutez la commande Get-ClientAccessService comme ci-dessous pour visualiser les différentes adresses Autodiscover déclarées au sein de notre serveur de messagerie Exchange.

Get-ClientAccessService | Format-List Identity, AutoDiscoverServiceInternalUri, AutoDiscoverSiteScope

La commande ci-dessus fonctionne avec Exchange Server 2016 et Exchange Server 2019. Sur les versions plus anciennes, utilisez celle-ci :

Get-ClientAccessServer | Format-List Identity, AutoDiscoverServiceInternalUri, AutoDiscoverSiteScope

L'adresse retournée par cette commande n'est pas celle à laquelle on pouvait s'attendre puisqu'elle utilise le nom du serveur sur le domaine local. Dans un environnement avec plusieurs serveurs Exchange ou plusieurs sites, plusieurs lignes peuvent être retournées par cette commande.

Exchange - Get-ClientAccessService - Autodiscover

Désormais, avec la commande Set-ClientAccessService, on va modifier cette URL de manière à utiliser l'enregistrement DNS "autodiscover.florianburnel.fr" qui est un nom DNS qui peut être résolu en interne et en externe (avec deux adresses IP différentes, conformément à la configuration mise en place précédemment). On précise le serveur via le paramètre -Identity. Cela donne :

Set-ClientAccessService -Identity "AZ-EXCHANGE" -AutoDiscoverServiceInternalUri "https://autodiscover.florianburnel.fr/Autodiscover/Autodiscover.xml"

À partir de là, si l'on rappelle la première commande, on peut voir que l'adresse est bien modifiée :

Exchange - Set-ClientAccessService - Autodiscover

Puisqu'il s'agit d'une URL, il faut considérer que c'est lié au serveur Web IIS. De ce fait, à partir d'une console PowerShell ouverte en tant qu'admin, exécutez cette commande pour redémarrer IIS :

iisreset /restart
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted

Voilà, la configuration est terminée.

IV. Vérifier et tester la configuration Autodiscover

Pour vérifier et tester la configuration que l'on vient de mettre en place, nous avons plusieurs méthodes :

  • Le client de messagerie Outlook
    • Méthode que nous allons voir dans cet article, qui permet de tester directement à partir d'un poste client en conditions réelles
  • Le site testconnectivity.microsoft.com via les serveurs de Connectivité Outlook
    • Disponible sur cette page, mais qui retourne une erreur si le certificat n'est pas reconnu (ce qui est le cas, si vous suivez cette série d'articles)

Exchange - Autodiscover - Connexion Outlook - Etape 3

  • PowerShell avec la commande Test-OutlookWebServices
    • Commande du module ExchangePowerShell, disponible via l'Exchange Management Shell, mais qui implique de configurer le serveur (BackConnectionHostNames) vu qu'on interroge le serveur via la boucle locale - Sinon l'erreur "System.Net.WebException: The remote server returned an error: (401) Unauthorized." est retournée. Peu pratique.

Regardons de plus près la méthode avec Outlook...

Lorsque vous allez ouvrir Outlook, il va essayer de se configurer tout seul comme un grand grâce à l'Autodiscover (il va rechercher un compte de messagerie correspondant à la session Windows puisque l'adresse e-mail est renseignée dans le profil Active Directory). Puisque l'on a part encore vu la configuration du certificat, il y a une alerte de sécurité relative au certificat qui apparaît à l'écran (il faudra cliquer sur "Oui"), comme ceci :

Au final, le compte a été ajouté automatiquement : c'est très pratique ! En toute logique, l'Autodiscover fonctionne et il est correctement configuré.

Pour le vérifier ou éventuellement faire du troubleshooting en cas de problème, on peut Sur l'icône Outlook disponible en bas à droite, effectuez un "CTRL + clic droit" pour que l'entrée "Tester la configuration automatique du courrier" soit visible dans le menu contextuel. Cliquez dessus.

La fenêtre ci-dessous va apparaître. Elle va reprendre automatiquement votre adresse de courrier. Il n'est pas nécessaire de mettre le mot de passe pour tester la connectivité. Décochez toutes les cases sauf "Utiliser la découverte automatique" et cliquez sur "Tester". Basculez sur l'onglet "Journal", et là, vous devez visualiser le statut "Réussite". C'est le signe que l'Autodiscover fonctionne bien !

V. Conclusion

Suite à la lecture de cet article, vous êtes en mesure de configurer l'Autodiscover sur votre serveur Microsoft Exchange Server ! Une question ? Un problème ? Vous pouvez poster un commentaire sur cet article ou venir en discuter sur le serveur Discord de la communauté IT-Connect !

L'article Microsoft Exchange Server 2019 – Découverte et configuration de l’Autodiscover est disponible sur IT-Connect : IT-Connect.

Stellar Repair for Exchange : récupérer des données dans une base Exchange corrompue

30 novembre 2022 à 08:47

I. Présentation

Dans cet article, nous allons découvrir Stellar Repair for Exchange, un outil qui peut vous "sauver la vie" lorsque vous devez récupérer des données au sein d'une base de données Exchange corrompue. Malheureusement, ce type d'incident peut se produire suite à un incident logiciel ou matériel, comme un défaut sur l'espace de stockage qui héberge la base de données Exchange.

La solution proposée par Stellar permet d'aller plus loin que l'utilitaire natif livré avec Exchange : EseUtil. Cet utilitaire, bien qu'il soit utile pour réparer une base de données corrompue ou effectuer diverses opérations de maintenance sur les bases de données Exchange, n'est pas toujours efficace.

Note : pour rappel, les bases de données Exchange sont au format EDB (Exchange DataBase).

Le logiciel Stellar Repair for Exchange est payant (à partir de 399 euros) et il prend en charge l'ensemble des versions d'Exchange, de la version 5.5 à Exchange Server 2019. Voici les fonctionnalités principales de ce logiciel dont l'objectif est de permettre la restauration de données contenues dans une base Exchange corrompue :

  • Récupérer des messages, des contacts, des calendriers, des tâches et des notes
  • Prendre en charge la récupération de fichiers EDB volumineux
  • Exporter les boîtes aux lettres restaurées vers un serveur Exchange ou Office 365 (Exchange Online)
  • Sauvegarder les fichiers en tant que fichier PST, MSG, EML, RTF, HTML et PDF

Vous pouvez le télécharger pour l'essayer à partir du lien suivant :

L'éditeur Stellar propose des outils de récupération de données pour les particuliers et les entreprises, avec un ensemble d'outils adaptés aux serveurs de messagerie Microsoft Exchange Server. Dans un article précédent, je vous ai déjà parlé du logiciel "Stellar Converter for EDB".

II. Installation de Stellar Repair for Exchange

Le logiciel de Stellar travaille sur une base de données Exchange démontée et hors ligne. Cela signifie que le logiciel peut être installé sur le serveur Exchange ou sur une autre machine, à condition que le fichier EDB soit accessible. Dans cet exemple, j'installe le software sur un serveur Exchange Server 2019.

Pour rappel, à partir du Centre d'administration Exchange, vous pouvez démonter une base de données via : Serveurs > Bases de données > Sélectionner la base de données > Démonter.

Exchange - Démonter une base de données

Après avoir téléchargé l'installeur, il faut lancer l'installation. La première bonne nouvelle, c'est que la langue française est disponible. Pour l'installation, il suffit de quelques clics, en laissant les options par défaut.

Installation de Stellar Repair for Exchange

C'est tout pour l'installation !

III. Utilisation de Stellar Repair for Exchange

Après l'installation, lorsque vous ouvrez l'application, vous êtes invité à choisir l'emplacement du fichier EDB à analyser. Si vous ne savez pas où est stocké ce fichier, cliquez sur "Rechercher" pour que l'application effectue une recherche à votre place.

Stellar Repair for Exchange - Etape 1

L'étape suivante consiste à choisir un mode d'analyse. Soit une analyse rapide, soit une analyse complète. Il vaut mieux essayer le mode rapide pour commencer, et s'orienter vers l'analyse complète si la première méthode ne donne pas de résultats satisfaisants. Sur une même base, il est possible de faire autant d'analyses que nécessaire.

Stellar Repair for Exchange - Etape 2

Une fois l'analyse terminée, les données récupérées sont visibles dans l'interface du logiciel. Pour les personnes habituées à manipuler la suite Microsoft Office et plus particulièrement Outlook, l'application est facile à prendre en main. Sur la gauche, la liste des boîtes aux lettres récupérées est visible, tandis qu'en bas, on peut naviguer entre le courrier, le courrier, les contacts, les tâches, etc... Comme on le fait dans Outlook.

Lorsque l'on s'intéresse aux boîtes aux lettres, l'outil offre la possibilité à l'administrateur de visualiser les boîtes aux lettres activées ou désactivées, les boîtes aux lettres partagées, ainsi que les boîtes aux lettres du système et les dossiers publics.

Stellar Repair for Exchange - Etape 3

Lorsque l'on navigue dans les données au travers de l'application Stellar, on est en phase de prévisualisation des données. La prévisualisation des données est disponible pour chaque section (contacts, e-mails, calendriers, etc.) et pour chaque compte identifié dans la base de données.

Stellar Repair for Exchange - Calendrier

L'application "Stellar Repair for Exchange" est capable d'exporter les données pour un seul compte ou pour un ensemble de comptes.

Stellar Repair for Exchange - Sauvegarder les données

Pour exporter les données récupérées au sein de la base de données corrompue, vous avez le choix entre plusieurs destinations :

  • Un serveur Exchange en ligne
  • Un environnement Office 365
  • Un fichier au format PST
  • Un dossier de messagerie "Public" (Exchange ou Office 365)
  • Un fichier MSG, EML, RTF, PDF ou HTML (pour les boîtes aux lettres)

Stellar Repair for Exchange - Choix de la destination

 

Si l'on prend l'exemple d'un serveur Exchange ou d'Office 365 comme destination, il sera nécessaire de déclarer un compte de messagerie (configuré dans Outlook) avec des droits d'administrateur Exchange sur la machine où l'application Stellar est installée pour que la récupération des données soit possible. Ensuite, il faut s'authentifier comme le montre la copie d'écran ci-dessous.

Une fois l'authentification réussie, il faudra effectuer la correspondance entre les boîtes aux lettres de la base corrompue et celles de la base en ligne. Ainsi, le logiciel sera capable de restaurer les éléments au bon endroit. C'est obligatoire d'effectuer cette correspondance (en mode automatique ou manuel) et l'application est capable de créer une boîte aux lettres si elle n'existe pas (vous définissez le nom complet, l'adresse e-mail, le mot de passe, ainsi que la database cible). Cette étape est appelée "Cartographier les boîtes aux lettres".

Lors de cette étape, l'administrateur peut aussi configurer la priorité des différentes boîtes aux lettres. Ainsi, les boîtes aux lettres critiques peuvent être traitées en priorité. Malgré tout, la restauration des données n'est pas effectuée boîte aux lettres par boîte aux lettres : l'application est capable de traiter plusieurs boîtes aux lettres en parallèle (cela est visible en temps réel lorsque l'on visualise la progression de la tâche). Voici un exemple :

Stellar Repair for Exchange - Cartographie

L'option "Appliquer les filtres" est intéressante également, car elle permet d'exclure certains messages, tels que les e-mails indésirables et les e-mails supprimés, ainsi que certains expéditeurs, dans le but de gagner du temps lors de la récupération des données.

Quand tout est configuré, l'opération doit être lancée en cliquant sur le bouton "Exporter" en bas à droite. Une fois l'opération terminée, l'application indique un compte-rendu afin de préciser à l'administrateur s'il y a eu des problèmes avec certaines boîtes aux lettres.

Il ne reste plus qu'à vérifier les données sur la base en production, et réessayer de relancer sur les éléments en cas d'erreurs. Il faut aussi garder à l'esprit qu'il y a un mode qui permet d'effectuer une recherche plus approfondie sur la base.

IV. Conclusion

Stellar Repair for Exchange est une application aboutie et simple à utiliser. En pratique, elle est efficace et grâce aux différentes options, on peut configurer finement la tâche de restauration de données. Même si l'on aimerait ne jamais avoir recours à cette application, lorsqu'un incident se produit, elle peut clairement vous sauver la mise d'autant plus si l'utilitaire EseUtil se montre inefficace dans la réparation d'une base Exchange.

Je n'irais pas jusqu'à dire qu'il est possible d'utiliser cette application pour migrer d'Exchange on-premise à Office 365, mais le fait que le logiciel prenne en charge diverses destinations pour la restauration des données, ouvre des possibilités. Même si l'application est relativement simple à utiliser, sachez qu'il existe une documentation officielle, accessible en ligne et en français (voir cette page) qui est là pour vous accompagner également.

Si vous avez déjà utilisé ce logiciel et que vous souhaitez faire un retour d'expérience, n'hésitez pas à poster un commentaire sur cet article !

L'article Stellar Repair for Exchange : récupérer des données dans une base Exchange corrompue est disponible sur IT-Connect : IT-Connect.

Un nouvel exploit ProxyNotShell pour compromettre massivement les serveurs Microsoft Exchange

21 novembre 2022 à 08:35

À l'occasion du Patch Tuesday de Novembre 2022, Microsoft a corrigé les vulnérabilités ProxyNotShell au sein d'Exchange Server. Toutefois, ces vulnérabilités restent très exploitées et un nouvel exploit est disponible : de quoi permettre une exploitation massive.

Depuis plusieurs semaines, on entend parler des failles de sécurité ProxyNotShell puisqu'elles sont connues depuis septembre 2022. Associé aux références CVE-2022-41082 et CVE-2022-41040, ces vulnérabilités permettent à un attaquant d'effectuer une élévation de privilèges et de compromettre le serveur de messagerie Exchange. Pour rappel, ces vulnérabilités affectent Exchange Server 2013, 2016 et 2019.

Pour se protéger, il convient de mettre à jour son serveur Exchange de manière à bénéficier des derniers correctifs de sécurité. En complément, vous pouvez mettre en place l'outil gratuit CrowdSec afin de bloquer les attaques courantes ainsi que les attaques plus spécifiques comme celle-ci. J'en ai parlé récemment dans un article dédié, à l'occasion de ma série d'articles sur l'installation et la configuration d'Exchange.

Le chercheur en sécurité Janggggg a mis en ligne un exploit PoC utilisé par des pirates dans le cadre d'attaques et qui permet de déployer une porte dérobée sur les serveurs Exchange. Dans le même temps, Will Dormann a testé cet exploit et il a confirmé qu'il fonctionnait contre les serveurs Exchange Server 2016 et 2019. Pour qu'il fonctionne avec Exchange Server 2013, il est nécessaire de faire quelques ajustements dans le code.

La tendance est claire : les cybercriminels cherchent à exploiter les vulnérabilités ProxyNotShell pour compromettre des serveurs Exchange et l'utiliser comme point de connexion initial dans le but de compromettre le reste de l'infrastructure. Ce nouvel exploit est la preuve que la menace est réelle.

Dans certains cas, comme l'a révélé l'entreprise GreyNoise, l'objectif est de déployer le web shell Chinese Chopper après avoir exploité les deux CVE citées précédemment (l'exploitation en chaîne de ces deux failles est nécessaire pour compromettre le serveur).

Si vous avez un serveur Exchange, pensez à le mettre à jour sans plus attendre.

Source

L'article Un nouvel exploit ProxyNotShell pour compromettre massivement les serveurs Microsoft Exchange est disponible sur IT-Connect : IT-Connect.

Comment protéger un serveur Microsoft Exchange avec CrowdSec ?

17 novembre 2022 à 16:45

I. Présentation

Dans ce tutoriel, nous allons voir comment sécuriser un serveur de messagerie Microsoft Exchange avec le pare-feu collaboratif CrowdSec ! Le fait d'installer CrowdSec sur un serveur Microsoft Exchange va permettre de se protéger contre les attaques courantes, mais également contre les nouvelles menaces.

Par exemple, je pense à la faille de sécurité ProxyNotShell qui a fait parler d'elle en octobre 2022 : CrowdSec est capable de détecter les tentatives d'exploitation et de bloquer les adresses IP malveillantes, grâce au fait qu'il existe une collection pour IIS et les attaques basées sur les protocoles HTTP/HTTPS. On peut également citer des cas plus classiques : un brute force sur l'interface du webmail d'Exchange.

De par sa fonction, un serveur Exchange sera plus ou moins exposé sur Internet selon l'architecture de votre SI (par exemple, la présence ou non d'un reverse proxy). Toutefois, il a besoin de pouvoir communiquer vers l'extérieur et d'être joignable depuis l'extérieur pour envoyer et recevoir les e-mails à destination des boîtes aux lettres de vos utilisateurs.

Ce même serveur sera aussi joignable par l'intermédiaire d'un Webmail qui permet aux utilisateurs de consulter leurs e-mails à partir d'un navigateur. Ceci implique la présence d'un serveur Web IIS, qui héberge à la fois le Webmail et le Centre d'administration d'Exchange. D'ailleurs, lorsqu'il y a la compromission d'un serveur Exchange dans le cadre d'une cyberattaque, cela passe majoritairement par les accès HTTP/HTTPS : d'où l'intérêt de se protéger.

CrowdSec Windows - Protéger OWA
Aperçu du Webmail d'Exchange (OWA)

Cet article fait office de suite à mon premier article sur l'installation d'un serveur Exchange Server 2019. Pour l'installation de Microsoft Exchange Server en lui-même, je vous invite à lire mon précédent tutoriel :

En complément, je vous encourage aussi à restreindre l'accès au Centre d'administration Exchange :

II. Mise en place de CrowdSec sur Windows

A. Installation de l'agent CrowdSec

J'ai déjà évoqué l'installation de CrowdSec sur Windows dans un précédent article, mais il s'agissait de la version Alpha. Désormais, l'agent CrowdSec pour Windows est disponible en version stable, ce qui signifie qu'il est prêt pour être mis en place en production.

Note : si vous avez mis en place la version alpha sur votre serveur, vous devez procéder à une désinstallation de CrowdSec avant d'installer cette nouvelle version.

Tout d'abord, vous devez télécharger le package MSI sur le dépôt GitHub officiel de CrowdSec.

Lors de l'installation, le package MSI de CrowdSec va réaliser les actions suivantes :

  • Installation de CrowdSec en lui-même
  • Intégration de la collection Windows (les détails sont disponibles ici)
  • Inscription de l'instance CrowdSec avec l'API Central
  • Inscription du service CrowdSec au sein de Windows (démarrage automatique)

Une fois que c'est fait, démarrez l'installation. Il suffit de suivre les étapes sans apporter de modifications... Ensuite, comptez 2 minutes environ pour l'installation de l'agent.

Installer CrowdSec sur Windows pour Exchange Server

Dès que l'agent CrowdSec est en place, nous avons accès à la ligne de commande "cscli" qui permet de manager son instance CrowdSec en ligne de commande.

Pour lister les collections actuelles :

cscli collections list

Pour lister les bouncers actuels (aucun par défaut) :

cscli bouncers list

CrowdSec Windows - Lister les collections et les bouncers

B. Installation de la collection IIS

Sur Windows, CrowdSec met en place nativement la collection "crowdsecurity/windows", mais ce n'est pas suffisant pour protéger notre serveur Exchange. Nous devons ajouter la collection pour IIS, ce qui va implicitement ajouter deux autres collections permettant de détecter les attaques Web.

Cette collection s'installe à partir de cette commande :

cscli collections install crowdsecurity/iis

Quelques secondes plus tard, nous pouvons lister les collections installées afin de constater la présence des nouvelles collections.

CrowdSec Windows - Lister les collections

D'ailleurs, pour justifier ce que je disais en introduction au sujet de la vulnérabilité ProxyNotShell, nous pouvons regarder le détail de la collection "crowdsecurity/http-cve". Ici, on peut constater la présence d'un scénario de détection nommé "crowdsecurity/CVE-2022-41082" correspondant à cette vulnérabilité.

cscli collections inspect crowdsecurity/http-cve

CrowdSec Windows - Détails de la collection http-cve

Passons à l'étape suivante.

C. Installation du bouncer firewall Windows

Nous devons mettre en place le bouncer "firewall" pour Windows, sinon les attaques seront détectées, mais pas bloquées. Cliquez sur le lien ci-dessous, puis sur le bouton "Download" afin de télécharger le package MSI.

L'installation s'effectue en quelques clics : il suffit de suivre l'assistant.

CrowdSec Windows - Installation du bouncer firewall

Une fois que c'est terminé, la commande ci-dessous permettra de visualiser la présence du bouncer.

cscli bouncers list

CrowdSec Windows - Lister les bouncers

Passons à l'étape suivante.

D. Ajouter la prise en charge des logs IIS

Pour que CrowdSec s'intéresse aux journaux générés par IIS, et par extension correspondant aux accès sur les portails OWA et ECP d'Exchange, nous devons lui indiquer les chemins vers les fichiers journaux à analyser.

Vous devez modifier le fichier suivant :

C:\ProgramData\CrowdSec\config\acquis.yaml

Afin d'ajouter les lignes suivantes à la suite :

---
use_time_machine: true
filenames:
  - C:\inetpub\logs\LogFiles\*\*.log
labels:
  type: iis

Vous pouvez voir la présence d'un chemin "dynamique" qui se caractérise par la présence du caractère wildcard (*) : "C:\inetpub\logs\LogFiles\*\*.log". Cette valeur va permettre à CrowdSec de trouver et lire les fichiers de logs situés dans l'arborescence "C:\inetpub\logs\LogFiles\" et de les analyser. Ce qui signifie que si vous utilisez un autre chemin, voire même un autre volume pour les logs, vous devez adapter cette valeur.

Exchange - CrowdSec - Config YAML IIS

Au-delà du chemin vers les fichiers journaux, ce bloc de configuration que l'on vient d'ajouter contient un paramètre nommé use_time_machine. Il est important, car IIS n'écrit pas les logs en temps réel dans le fichier journal, mais il écrit les nouveaux événements en bloc, chaque minute. Grâce à ce paramètre, CrowdSec va lire la date et l'heure de chaque ligne pour se repérer et traiter les événements chronologiquement, ceci évite de faux positifs.

Par contre, si vous n'utilisez pas les fichiers de logs, mais l'observateur d'événements, vous devez utiliser ce bout de code et non celui mentionné précédemment :

---
source: wineventlog
event_channel: Microsoft-IIS-Logging/Logs
event_ids:
  - 6200
event_level: information
labels:
  type: iis

Enregistrez le fichier acquis.yaml et vous pouvez le fermer.

Pour finir, nous devons redémarrer le service CrowdSec. Cette opération s'effectue en PowerShell avec cette commande :

Restart-Service crowdsec

La mise en place de CrowdSec est terminée ! Maintenant, nous allons tester notre système de protection !

III. Le serveur Exchange est-il protégé ?

A. Brute force sur OWA - Webmail Exchange

Pour réaliser une attaque par brute force sur OWA, il y a plusieurs méthodes envisageables. Bien sûr, on peut le faire manuellement pour tester, mais on peut aussi utiliser quelque chose d'un peu plus automatisé pour simuler une attaque de type brute force. Ainsi, on va utiliser un script Bash nommé "OWA BRUTE" qui exécute Hydra (un outil offensif compatible avec de nombreux protocoles pour tester l'authentification à un service, un équipement, etc.) avec des paramètres spécifiques correspondants à Outlook Web Access.

Le script est disponible sur GitHub à l'adresse suivante :

Tout d'abord, nous devons installer Hydra et Git. Le premier est un prérequis pour utiliser le script et réaliser notre attaque, tandis que le second va servir à cloner le dépôt GitHub pour récupérer le script Bash (vous pouvez aussi faire un copier-coller du script dans un fichier...).

sudo apt-get update
sudo apt-get install hydra git

Une fois que c'est fait, on clone le projet GitHub dans "/home/florian" :

cd /home/florian/
git clone https://github.com/p0dalirius/owabrute

Puis, on crée un fichier "users.txt" dans lequel on indique quelques noms d'utilisateurs. On peut aussi imaginer que l'on récupère une liste sur Internet.

nano /home/florian/owabrute/users.txt

CrowdSec Windows - Fichiers avec les noms d'utilisateurs

Dans le même esprit, on crée un fichier "passwords.txt" avec les mots de passe à tester.

nano /home/florian/owabrute/passwords.txt

CrowdSec Windows - Fichiers avec les mots de passe

Ensuite, on se positionne dans le répertoire de OWA BRUTE pour ajouter les droits d'exécution sur le script Bash.

cd /home/florian/owabrute/
chmod +x owabrute.sh

Il ne reste plus qu'à lancer l'attaque en ciblant "mail.domaine.fr" puis en utilisant nos fichiers créés précédemment.

./owabrute.sh -d mail.domaine.fr -u ./users.txt -p ./passwords.txt

On peut voir que le script va tester chaque combinaison, tour à tour. Au final, il indiquera s'il a réussi ou non à trouver une combinaison valide. Toutefois, CrowdSec va intervenir....

CrowdSec Windows - Brute force avec OWA BRUTE

En effet, si je regarde du côté de mon serveur Exchange, je peux voir qu'il y a une nouvelle adresse IP bloquée à cause d'un brute force ("crowdsecurity/windows-bf"). L'agent CrowdSec a correctement bloqué l'adresse IP à l'origine de cette attaque.

CrowdSec Windows - Vérifier le blocage du brute force

Puisqu'ici nous sommes là pour faire des tests, nous pouvons débloquer notre adresse IP manuellement :

cscli decisions delete --ip X.X.X.X

Passons à une seconde démonstration.

B. Scan Web sur OWA

Dans le cas où un individu cherche à scanner votre serveur Web, en l'occurrence ici IIS utilisé par Exchange, il peut s'appuyer sur divers outils dont Nikto qui sert à analyser le niveau de sécurité d'un serveur Web. Pour cet exemple, OWA sera analysé avec l'outil Nikto : nous verrons si CrowdSec détecte ce qu'il se passe sur le serveur IIS...

Tout d'abord, installons cet outil :

sudo apt-get update
sudo apt-get install nikto

Puis, on lance le scanne à destination du webmail :

nikto -h https://mail.domaine.fr/owa

L'analyse va durer plusieurs minutes...

CrowdSec Windows - Scan avec nikto

...Sauf qu'au bout d'un moment, CrowdSec va se rendre compte que ce client Web effectue des actions suspectes et il va décider de le bloquer. Dans l'exemple ci-dessous, on peut voir la raison "http-sensitive-files" ce qui signifie que le client a essayé d'accéder à des fichiers sensibles.

CrowdSec Windows - Verifier le blocage de nikto

Dans ce second exemple, où l'on a effectué une action totalement différente en comparaison de la première tentative, CrowdSec est également parvenu à détecter nos actions malveillantes.

IV. Conclusion

Nous venons de voir comment mettre en place l'agent CrowdSec sur Windows de manière à protéger un serveur de messagerie Microsoft Exchange ! Ici, j'ai pris l'exemple d'Exchange Server 2019, mais cela s'applique aussi aux versions précédentes. Avec ces deux exemples rapides, mais concrets, nous avons pu voir l'efficacité de CrowdSec !

Je profite de cet article pour vous rappeler l'existence de la console CrowdSec qui vous permet de suivre les alertes remontées par un ou plusieurs agents CrowdSec à partir d'une console en mode Web. Pour en savoir plus sur la mise en place et l'ensemble des fonctionnalités, consultez cet article :

L'article Comment protéger un serveur Microsoft Exchange avec CrowdSec ? est disponible sur IT-Connect : IT-Connect.

Microsoft Exchange Server 2019 – Comprendre et configurer les enregistrements DNS

10 novembre 2022 à 16:45

I. Présentation

Dans ce nouvel épisode au sujet de Microsoft Exchange Server 2019, nous allons apprendre à configurer les enregistrements DNS nécessaires au bon fonctionnement de notre serveur de messagerie Exchange. Ces enregistrements, de différents types, sont indispensables. Au-delà d'en faire la configuration, il est important de connaître l'utilité de ces enregistrements DNS.

II. Exchange : les enregistrements DNS indispensables

Pour qu'un serveur de messagerie puisse fonctionner, que ce soit un serveur Exchange ou basé sur une autre solution, il y a des prérequis à respecter au niveau des enregistrements DNS. Les types d'enregistrements DNS "MX", "A", "CNAME" ou encore "SPF" sont généralement associés.

Les enregistrements DNS vont permettre aux clients et aux autres serveurs de messagerie de localiser notre serveur Exchange et de vérifier qu'il est bien légitime pour envoyer des e-mails avec ce domaine. Par ailleurs, ces enregistrements DNS vont permettre de configurer la fonctionnalité "Autodiscover", c'est-à-dire la découverte automatique, dont l'objectif est de faciliter la configuration des clients de messagerie (par exemple, l'ajout d'une boîte aux lettres dans Outlook). Ce point sera détaillé dans un prochain article.

Type d'enregistrement Nom DNS Valeur Priorité
A mail.domaine.fr Votre IP publique -
CNAME autodiscover.domaine.fr mail.domaine.fr -
MX @ mail.domaine.fr 10

A. Enregistrements DNS "MX"

Tout d'abord, nous avons l'enregistrement DNS de type "MX" correspondant à "Mail Exchange" (qui n'a rien à voir avec le nom de produit Microsoft Exchange) dont l'objectif est de permettre de localiser le(s) serveur(s) de messagerie associés à un nom de domaine. Au même titre qu'un enregistrement DNS peut permettre de trouver le serveur Web qui héberge le site Internet d'une entreprise, l'enregistrement MX est spécifique aux serveurs de messagerie.

Une fois le serveur de messagerie identifié grâce à l'enregistrement MX, l'e-mail pourra être envoyé. Cela signifie que l'enregistrement MX va permettre le routage des messages. Parfois, au lieu de router les flux directement vers un serveur de messagerie, on indique à la place un service anti-spam, ce qui permet de filtrer les e-mails avant qu'ils n'arrivent jusqu'au serveur Exchange.

Dans cet enregistrement DNS "MX" on va préciser le nom de domaine, le nom FQDN du serveur de messagerie (un autre enregistrement permettra de faire le lien entre ce nom complet FQDN et l'adresse IP du serveur), ainsi qu'une priorité et une durée de vie (TTL). La priorité est utile dans les projets importants où il y a plusieurs serveurs en parallèle, afin d'assurer une redondance. Dans notre cas, il n'y a qu'un seul serveur Exchange donc la priorité n'a pas un réel intérêt, mais c'est à connaître. Le serveur avec la priorité la plus faible sera consulté en premier.

Note : l'enregistrement MX doit impérativement pointer vers un domaine, au même titre qu'un enregistrement CNAME. L'enregistrement MX doit pointer vers un domaine associé à un enregistrement A (IPv4) ou AAAA (IPv6) mais par vers un CNAME.

B. Enregistrements DNS "A" et "CNAME"

Un enregistrement DNS de type A permettra d'indiquer l'adresse IPv4 du serveur de messagerie Exchange, en associant un sous-domaine tel que "mail.domaine.fr". Ici, on reprend le même nom de domaine que celui utilisé dans l'enregistrement MX (comme vous pouvez le voir dans le tableau ci-dessus).

Quant à l'enregistrement CNAME, on l'utilisera pour créer des alias, notamment sur la partie Autodiscover ou l'accès au Webmail (OWA).

C. Enregistrements DNS "SPF"

L'enregistrement DNS de type "TXT" permet de déclarer un "SPF" pour Sender Policy Framework joue un rôle important pour sécuriser un minimum le nom de domaine public. Grâce à lui, on peut déclarer quelles sont les adresses IP (IPv4 ou IPv6) ou les noms de domaine autorisés à envoyer des e-mails pour ce nom de domaine.

Autrement dit, nous devons autoriser le serveur Exchange à envoyer des e-mails pour ce domaine et lorsqu'un serveur de messagerie recevra un e-mail avec ce domaine de messagerie, il pourra le vérifier par lui-même grâce à la lecture de l'enregistrement SPF. Ce qui donne :

600 IN TXT "v=spf1 mx ~all"

Dans l'exemple ci-dessus, le fait de se référer à "mx" permet d'autoriser le serveur visé par l'enregistrement MX de la zone DNS.

Eventuellement, nous pourrions l'ajouter explicitement comme je l'ai fais ci-dessous, mais ce n'est pas indispensable.

v=spf1 mx a:mail.domaine.fr ~all

Dans le cas où l'on a besoin d'autoriser un autre serveur externe à envoyer des e-mails pour ce nom de domaine, nous pourrons aussi l'ajouter à cet enregistrement SPF. Il y a notamment les paramètres "ip4" et ip6" qui permettent de déclarer des adresses IPv4 et IPv6 pour spécifier un hôte.

D. Enregistrements DMARC (+ DKIM)

Pour finir, nous allons évoquer les enregistrements DMARC (et la norme DKIM qui est associée) : bien qu'ils ne soient pas indispensables pour que le serveur Exchange fonctionne et que l'on puisse envoyer/recevoir des e-mails, ils ne doivent pas être ignorés. Ils jouent un rôle important pour améliorer la sécurité et la délivrabilité des e-mails, ce qui évite de finir en spam dans certains cas.

DKIM pour Domain Keys Identified Mail est une norme d'authentification qui permet d'ajouter une signature chiffrée dans l'en-tête des e-mails que vous envoyez. Les e-mails restent accessibles en clair, mais l'intérêt c'est de lutter contre l'usurpation d'identité et l'altération des messages, car on est capable de vérifier que le serveur émetteur est bien qui il prétend être.

DMARC pour Domain-based Message Authentication, Reporting, and Conformance permet d'indiquer une politique à appliquer dans le cas où une usurpation d'identité est détectée. En effet, avec DKIM (et SPF) on authentifie et vérifie l'émetteur, mais que faire dans le cas où il y a un problème ? C'est là que DMARC entre en jeu et cette politique se définit au sein du DNS.

Pour la mise en œuvre de DKIM et DMARC, ce sera abordé dans un prochain épisode. Pour en savoir, vous pouvez lire cet article qui s'applique à Office 365 mais où les concepts de DKIM et DMARC sont détaillés.

III. Les enregistrements internes et externes

Un serveur de messagerie Exchange, au même titre qu'un Active Directory, s'appuie sur le DNS pour son fonctionnement. Ce serveur Exchange hébergé sur votre infrastructure (dans une DMZ) est accessible à la fois depuis l'extérieur et depuis l'intérieur de votre réseau local.

Les enregistrements DNS évoqués précédemment seront configurés sur la zone DNS publique, auprès du fournisseur que vous avez choisi au moment d'acheter votre nom de domaine. Par exemple, si l'on achète le nom de domaine "domaine.fr" chez OVHcloud, il faudra se connecter sur l'interface de gestion d'OVHcloud pour configurer la zone DNS. Ainsi, lorsqu'un hôte cherchera à localiser le serveur de messagerie pour ce domaine, il obtiendra l'adresse IP publique votre serveur Exchange.

Quand il est connecté à l'extérieur du réseau, c'est bien qu'il utilise l'adresse IP publique. Par exemple, un utilisateur connecté avec son PC au réseau d'un hôtel, ou encore un serveur de messagerie qui a besoin de contacter votre serveur pour vous transmettre un e-mail. Par contre, quand l'hôte est en interne (par exemple, l'ordinateur fixe connecté au réseau local), il doit utiliser les adresses IP locales (ici 10.10.100.211/24) pour atteindre le serveur Exchange. Sauf que ce n'est pas déclaré dans la zone DNS publique. De ce fait, il faut configurer le serveur DNS qui héberge déjà la zone DNS de l'Active Directory pour qu'il effectue la résolution avec l'adresse IP interne lorsque le client est en interne. Cela passe par la création d'une zone supplémentaire.

Exchange Server - DNS Interne et externe

En résumé, les connexions en provenance de l'extérieur doivent arriver sur l'adresse IP publique et les connexions internes doivent arriver sur l'adresse IP locale, même si l'on utilise les mêmes noms de domaine. Grâce au DNS, on peut arriver à ce résultat.

IV. Configurer les zones DNS

Le domaine "florianburnel.fr" est pris à titre d'exemple.

A. La zone DNS publique pour Exchange

La zone DNS publique doit être configurée auprès du fournisseur (registrar) où le domaine a été acquis. Pour la partie Exchange, je retrouve 4 enregistrements : MX, A, CNAME et SPF correspondants à ce que j'évoquais précédemment.

Exchange - Exemple zone DNS publique

En mode texte :

$TTL 3600
@ IN SOA dns104.ovh.net. tech.ovh.net. (2022111004 86400 3600 3600000 300)
  IN NS ns104.ovh.net.
  IN NS dns104.ovh.net.
  IN MX 10 mail.florianburnel.fr.
  600 IN TXT "v=spf1 mx ~all"
  autodiscover IN CNAME mail.florianburnel.fr.
  mail IN A 4.233.92.148

À partir d'une machine cliente, il est possible de vérifier la résolution de noms. On peut utiliser Resolve-DnsName en PowerShell, ou l'outil nslookup, voire même l'outil en ligne MXToolbox (qui a aussi une option pour valider votre SPF). On peut remarquer que c'est opérationnel et que l'adresse IP publique est associée à "mail.florianburnel.fr".

Resolve-DnsName - Exchange - Zone publique - Exemple 1

La résolution de noms fonctionne aussi pour l'enregistrement associé à l'Autodiscover.

Resolve-DnsName - Exchange - Zone publique - Exemple 2

Passons à la zone DNS privée.

B. La zone DNS interne pour Exchange

D'un point de vue du DNS interne, nous allons appliquer le principe du PinPoint DNS, c'est-à-dire que l'on va créer une zone "mail.domaine.fr" et une zone "autodiscover.domaine.fr" qui vont contenir un enregistrement de type A qui pointe vers l'adresse IP locale du serveur Exchange Server 2019. C'est préférable d'utiliser cette méthode plutôt que de créer la zone "domaine.fr" sinon cela oblige à maintenir la zone deux fois : en local et sur l'interface du fournisseur DNS.

Ouvrez la console DNS et créez une nouvelle zone. Un assistant s'exécute.

Exchange - Zone DNS interne Active Directory - Etape 1

Nous allons créer une zone primaire "Primary zone" et elle sera stockée dans l'Active Directory ("Store the zone in Active Directory").

Exchange - Zone DNS interne Active Directory - Etape 2

A l'étape suivante, on décide de répliquer cette zone auprès de tous les contrôleurs de domaine du domaine "it-connect.lan" pour unifier la résolution de noms pour cette zone.

Exchange - Zone DNS interne Active Directory - Etape 3

En ce qui concerne le nom de la zone, nous allons indiquer "mail.florianburnel.fr" pour définir un enregistrement local personnalisé uniquement pour ce sous-domaine.

Exchange - Zone DNS interne Active Directory - Etape 4

On poursuit en choisissant de refuser les mises à jour dynamiques ("Do not allow dynamic updates"). Puis, on finalise l'ajout de la zone.

Exchange - Zone DNS interne Active Directory - Etape 5

Dans cette nouvelle zone, on ajoute un nouvel hôte via un enregistrement de type "A".

Exchange - Zone DNS interne Active Directory - Etape 6

Nous n'indiquons pas de nom, car on souhaite jouer sur la résolution "mail.florianburnel.fr", et non d'un autre hôte. Pour l'adresse IP, il faut indiquer l'adresse IP privée du serveur Exchange, à savoir "10.10.100.211" dans mon cas. Ainsi, la résolution s'effectuera sur l'adresse IP interne pour cette adresse.

Exchange - Zone DNS interne Active Directory - Etape 7

Répétez l'opération pour la zone Autodiscover, à savoir "autodiscover.florianburnel.fr" dans mon cas et créez le même enregistrement A. Au final, vous obtenez 2 nouvelles zones.

Exchange - Zone DNS interne Active Directory - Etape 8

À partir du serveur ou d'un hôte qui utilise ce serveur comme DNS, on peut tester la résolution de noms. Cette fois-ci, c'est bien l'adresse IP "10.10.100.211" qui est renvoyée à la place de l'adresse IP publique. Cela fonctionne !

Exchange - Zone DNS interne Active Directory - Etape 9

Une autre méthode basée sur le principe du "Split-Brain DNS" consiste à créer des politiques au niveau du serveur DNS. Ce n'est pas très user-friendly comme méthode si vous n'êtes pas à l'aise avec PowerShell. Vous pouvez lire ces deux articles pour approfondir le sujet :

V. Conclusion

Nous venons de voir les grands principes des enregistrements DNS avec les serveurs de messagerie, en prenant l'exemple d'Exchange Server. Puis, nous avons également vu comment effectuer la configuration des zones DNS externes et internes.

L'article Microsoft Exchange Server 2019 – Comprendre et configurer les enregistrements DNS est disponible sur IT-Connect : IT-Connect.

Exchange 2019 : comment ajouter un nouveau domaine ?

7 novembre 2022 à 16:45

I. Présentation

Dans ce tutoriel, nous allons voir comment ajouter un nouveau domaine de messagerie sur un serveur Exchange Server 2019. Ce domaine sera utilisable pour les nouvelles boîtes aux lettres créées. Nous verrons comment le définir par défaut, mais aussi comment le définir en tant que suffixe UPN dans l'Active Directory pour simplifier l'authentification des utilisateurs.

On part du principe que l'on va ajouter le domaine "domaine.fr" à notre serveur Exchange. Ainsi, les utilisateurs pourront bénéficier d'une adresse e-mail avec ce domaine de messagerie. Côté Active Directory, ce domaine n'est pas connu au moment où il est ajouté à Exchange Server. Un utilisateur avec l'e-mail "[email protected]" devra s'authentifier sur le serveur Exchange avec son compte Active Directory, donc potentiellement "[email protected]" (si je reprends le domaine de ce lab) : l'utilisateur final doit mémoriser deux informations (son identifiant AD et son adresse e-mail).

En déclarant "domaine.fr" comme suffixe UPN dans l'Active Directory, l'utilisateur aura l'adresse e-mail "[email protected]" et il aura aussi la valeur "[email protected]" pour l'attribut "UserPrincipalName" de son compte AD. Ainsi, il pourra s'authentifier avec "[email protected]" sur Exchange mais aussi sur les ordinateurs du domaine !

La procédure étape par étape est disponible dans la vidéo correspondante à cette épisode. Ici, je vous donne les étapes de manière plus synthétique.

II. Ajouter un domaine

Commençons par la procédure pour ajouter un domaine, ce qui est réalisable à partir du Centre d'administration Exchange ou d'Exchange Management Shell.

À partir du Centre d'administration Exchange :

1 - Cliquez sur "Flux de courrier" (Mail flow)

2 - Cliquez sur l'onglet "Domaines acceptés"

3 - Ajoutez un nouveau domaine de messagerie avec l'option "Le domaine accepté fait autorité"

4 - Validez

5 - Éditez le domaine pour cocher l'option "Définir ce domaine comme domaine par défaut."

Si c'est un domaine externe que vous possédez, il est important d'indiquer que votre serveur fait autorité pour ce domaine. Cela signifie que votre serveur de messagerie est le serveur qui gère les e-mails pour ce domaine, ce qui se traduira aussi au niveau des enregistrements DNS notamment avec l'enregistrement MX (comme évoqué lors de l'installation).

Avec Exchange Management Shell :

On peut ajouter le domaine :

New-AcceptedDomain -DomainName domaine.fr -DomainType Authoritative -Name domaine.fr

Puis, on si on veut le mettre par défaut, on peut le modifier à tout moment :

Set-AcceptedDomain -Identity domaine.fr -MakeDefault $true

Passons à la suite.

III. Éditer la stratégie d'adresse de courrier

La seconde étape consiste à modifier la stratégie d'adresse de courrier pour attribuer le domaine "domaine.fr" à la place de "it-connect.lan". Sinon, le domaine local sera utilisé pour les nouvelles adresses e-mails, malgré que l'on ait un nouveau domaine par défaut.

Il est possible de créer diverses stratégies pour appliquer des formats d'adresses différents en fonction des types de ressources. Par exemple, une stratégie qui s'applique sur tous les types (comme celle par défaut) ou une stratégie qui s'applique uniquement sur les boîtes aux lettres. Dans cet exemple, j'édite la stratégie par défaut.

1 - Cliquez sur "Flux de courrier" (Mail flow)

2 - Cliquez sur l'onglet "Stratégies d'adresses de courrier"

3 - Éditez la "Default Policy"

4 - Cliquez sur "Format de l'adresse de courrier" et modifiez le domaine de "SMTP" pour que ça corresponde au nouveau domaine (à la place de "it-connect.lan").

Exchange 2019 - Modifier stratégie adresse de courrier

5 - Validez

A partir de là, si l'on crée une boite aux lettres, elle bénéficiera du domaine "@domaine.fr" tandis qu'au niveau de l'Active Directory, le domaine local sera utilisé pour l'authentification.

IV. Déclarer le suffixe UPN dans l'Active Directory

Pour déclarer un nouveau suffixe UPN correspondant au domaine de messagerie, il faut accéder aux propriétés de la console "Domaines et approbations Active Directory" comme expliqué dans ce tutoriel :

Il suffit de déclarer le domaine dans cette console.

Exchange Server 2019 - Suffixe UPN Active Directory

Une fois que c'est fait, vous pouvez créer votre boîte aux lettres ! Elle va bénéficier du domaine "@domaine.fr" et le compte Active Directory qui sera généré pourra bénéficier aussi de ce domaine. De ce fait, l'utilisateur pourra s'authentifier avec l'adresse "[email protected]" dans Exchange et sur son PC, avec le même mot de passe.

Pour créer une boîte aux lettres à partir du Centre d'administration Exchange, vous devez cliquer sur le menu suivant : Destinataire > Boites aux lettres > "+" > Boites aux lettres utilisateur. Ici, on choisit le domaine de messagerie pour le nom d'ouverture de session, tandis que pour la boîte aux lettres, c'est la stratégie Exchange qui va faire en sorte d'affecter le nom de domaine.

Exchange - Choix du suffixe UPN

Ensuite, dans l'Active Directory, on visualise bien les informations :

Si vous avez déjà créé des boîtes aux lettres et que l'UPN contient le nom de domaine Active Directory, vous pouvez repasser sur les comptes pour changer la valeur.

V. Conclusion

Voilà, nous venons de voir comment ajouter un nouveau domaine sur un serveur de messagerie Exchange ! Si vous avez besoin d'être guidé plus précisément, regardez la vidéo puisque j'effectue ces actions pas à pas.

L'article Exchange 2019 : comment ajouter un nouveau domaine ? est disponible sur IT-Connect : IT-Connect.

Désactiver les accès externes au Centre d’administration Exchange

3 novembre 2022 à 09:00

I. Présentation

Après avoir vu comment installer Exchange Server 2019 sur Windows Server 2022, nous allons voir comment protéger l'interface d'administration d'Exchange appelée "Centre d'administration Exchange" (ou ECP / EAC) en limitant l'accès à quelques adresses IP sources.

Je vous rappelle que par défaut, le Centre d'administration Exchange est accessible depuis le serveur Exchange en lui-même, depuis une machine du réseau local, mais aussi à partir d'Internet (si vous avez autorisé le flux HTTPS pour un accès au Webmail). Pour des raisons évidentes de sécurité, il est préférable de limiter l'accès à la console d'administration à partir de certaines adresses IP, ou au pire, à partir du réseau local. Il vaut mieux éviter que cette console soit accessible depuis l'extérieur.

Puisque le protocole HTTPS est utilisé aussi pour accéder au Webmail, nous ne pouvons pas jouer directement avec le pare-feu de Windows, car on couperait aussi l'accès au Webmail. La restriction doit être appliquée sur une couche supérieure. Nous avons deux solutions pour appliquer des restrictions par adresses IP :

  • Configurer le serveur Web IIS grâce au module de restriction par adresses IP
  • Configurer une "Client Access Rules" dans Exchange 2019 (pas disponible sur les versions antérieures)

II. Méthode n°1 : restriction via IIS

A. Installer la fonction "Restrictions par adresse IP et domaine"

Commençons par cette première méthode, plus traditionnelle on peut dire.

Sur votre serveur Exchange, dégainez la console PowerShell en tant qu'administrateur et exécutez la commande suivante :

Install-WindowsFeature -Name Web-IP-Security

Cette commande revient à installer la fonctionnalité suivante dans IIS, à partir du gestionnaire de serveur :

Une fois l'installation effectuée, passez à la suite. Il n'est pas utile de redémarrer le serveur.

B. Restreindre l'accès à l'ECP d'Exchange

Ouvrez la console de management d'IIS et déroulez la section "Sites". Ici, cliquez sur "Default Web Site" (1), puis sur "ecp" (2) afin d'accéder à "IP Address and Domain Restrictions" (ou  "Restrictions par adresse IP et domaine" en français).

Exchange 2019 - Configurer site ECP

Dans la section qui s'ouvre, cliquez sur "Add Allow Entry" (1) pour ajouter une nouvelle autorisation. L'objectif ici est d'indiquer quel est la machine ou le sous-réseau autorisé à accéder au Centre d'administration Exchange. Il est possible d'ajouter plusieurs règles d'autorisation. Dans cet exemple, j'autorise les connexions à ECP aux machines du sous-réseau "10.10.100.0/24" (2). Quand c'est fait, validez avec "OK" (3).

Exchange 2019 - Autoriser réseau à accéder à ECP

Une fois que votre règle est définie (c'est modifiable par la suite), cliquez sur "Edit Feature Settings" (1) afin de modifier l'action à appliquer pour les clients non autorisés. Par défaut, c'est autorisé, donc nous devons inverser ce comportement. Choisissez "Deny" (2) et pour l'action à réaliser, choisissez "Abort" (3) pour couper la connexion avec le client qui tente de se connecter. Validez avec "OK" (4).

Exchange 2019 - Sécuriser Centre administration Exchange

Pour finir, cliquez sur "Default Web Site" à gauche puis à droite sur le bouton "Restart" pour redémarrer le site IIS dans le but d'appliquer la modification.

Exchange 2019 - Redémarrer le site IIS

À partir d'un client autorisé, l'accès au Centre d'administration Exchange doit fonctionner normalement. Tandis qu'à partir d'un client non autorisé, une erreur doit s'afficher, comme ceci :

Restreindre accès centre admin Exchange

III. Méthode n°2 : Client Access Rules

Pour protéger le centre d'administration Exchange, nous pouvons mettre en place une règle Client Access Rules. C'est une méthode officielle dont la configuration s'effectue uniquement en PowerShell à partir de l'Exchange Management Shell.

Note : avec les règles Client Access Rules, il est possible d'aller plus loin qu'une restriction basée sur les adresses IP. Par exemple, on peut s'appuyer sur la valeur d'un attribut dans l'Active Directory.

Je vous invite à ouvrir la console Exchange Management Shell.

Tout d'abord, vous pouvez lister les règles en place. Par défaut, il n'y en a pas.

Get-ClientAccessRule

Ensuite, nous allons mettre en place une règle pour toujours autoriser le Remote PowerShell afin de ne pas perdre la main sur l'Exchange si l'on créer une mauvaise règle... C'est une recommandation de Microsoft et l'entreprise américaine fournie même la commande pour créer cette règle :

New-ClientAccessRule -Name "Always Allow Remote PowerShell" -Action AllowAccess -AnyOfProtocols RemotePowerShell -Priority 1

La règle avec la priorité 1 sera donc celle-ci. Ensuite, nous allons créer une nouvelle règle sur le même principe. Cette règle permet de refuser l'accès au Centre d'administration Exchange sauf pour les machines qui appartiennent au réseau "10.10.100.0/24". Ce qui donne :

New-ClientAccessRule -Name "Allow ECP console only for 10.10.100.0/24" -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -ExceptAnyOfClientIPAddressesOrRanges 10.10.100.0/24 -Priority 2

Suite à l'exécution de cette commande, vous pouvez lister vos règles :

Exchange 2019 - Client Access Rules ECP

Une fois la règle en place, vous pouvez tester pour voir si la restriction s'applique bien... Là, je parviens à me connecter à la page d'authentification d'ECP, et même à me connecter. Par contre, je ne peux pas aller plus loin, car la règle se déclenche comme le montre l'image ci-dessous. On peut dire que c'est cohérent : ce n'est pas IIS qui me bloque, mais Exchange.

Centre administration Exchange bloqué par une règle

Ce n'est pas ce que vous souhaitiez ? Pas de soucis, vous pouvez supprimer la règle en précisant son nom :

Remove-ClientAccessRule "Allow ECP console only for 10.10.100.0/24"

L'aide complète sur les Client Access Rules d'Exchange 2019 est disponible sur le site de Microsoft :

IV. Conclusion

Nous venons de voir comment restreindre l'accès au centre d'administration Exchange en appliquant une restriction basée sur les adresses IP. Cela n'a pas d'impact sur le Webmail Exchange en lui-même, mais c'est une action recommandée pour protéger l'interface d'administration. L'idéal étant de permettre l'accès à partir d'une ou plusieurs machines de management (ou un VLAN de management), et refuser les accès en provenance de l'extérieur ainsi que les accès provenant du réseau local (hors machines déclarées).

L'article Désactiver les accès externes au Centre d’administration Exchange est disponible sur IT-Connect : IT-Connect.

Installation pas à pas de Microsoft Exchange 2019 sur Windows Server 2022

2 novembre 2022 à 18:23

I. Présentation

Dans ce tutoriel, nous allons apprendre à mettre en place un serveur de messagerie Microsoft Exchange Server 2019 sous Windows Server 2022. Vous pouvez aussi l'installer sur Windows Server 2019 (mais pas une version plus ancienne). Même si Microsoft 365 est une solution très à la mode et qu'elle intègre Exchange Online, de nombreuses entreprises se tournent encore vers un serveur de messagerie Exchange "classique". D'ailleurs, Microsoft souhaite poursuivre l'aventure avec Exchange puisqu'une nouvelle version est prévue pour 2025 afin de prendre le relais avec Exchange Server 2019.

Note : Exchange Server 2019 prend en charge Windows Server 2022 depuis que la CU12 (2022H1) est sortie.

Voici quelques informations sur ma VM qui va accueillir Exchange 2019 :

  • Nom : AZ-EXCHANGE
  • Adresse IP : 10.10.100.211/24
  • Système d'exploitation : Windows Server 2022 Datacenter
  • RAM : 16 Go
  • vCPU : 4
  • Stockage : un volume NTFS pour le système et un volume ReFS pour la base de données et les logs

Microsoft Exchange est un sujet très vaste. Dans cet article, je me concentre sur les prérequis, la préparation du serveur, l'installation et une première connexion sur les différentes consoles.

Note : cet article ne traite pas la migration d'Exchange. Ici, c'est une installation en partant de zéro qui est effectuée.

II. Prérequis Microsoft Exchange 2019

Avant d'installer Microsoft Exchange 2019 (ou une autre version), il convient de prendre connaissance de certains prérequis. C'est ce que je vous propose en premier lieu. Ensuite, nous allons passer à la phase de préparation du serveur Exchange, toujours avant d'installer Exchange en lui-même.

  • Prérequis pour le stockage Exchange

Exchange Server supporte aussi bien les volumes formatés en NTFS qu'en ReFS, en fonction de l'usage qui est fait du volume, car ReFS n'est pas utilisable pour le système et les binaires d'Exchange. Dans la documentation de Microsoft, on peut lire :

    • Au moins 30 Go de libres sur la partition où est installé Exchange
    • Au moins 200 Mo de libres sur la partition du système
    • Au moins 500 Mo de libres sur la partition qui contient la base de données de file d'attente des messages

En réalité, il faudra prévoir beaucoup plus large en espace disque pour la base de données : tout dépend du nombre d'utilisateurs et de leur manière d'utiliser la messagerie...

  • Créer les enregistrements DNS (MX) correspondants à ce serveur Exchange

Vous devez configurer les enregistrements DNS suivants pour que votre serveur Exchange soit localisable. Les valeurs ci-dessous sont données à titre d'exemple.

Type d'enregistrement Nom DNS Valeur Priorité
A mail.domaine.fr Votre IP publique -
CNAME autodiscover.domaine.fr mail.domaine.fr -
MX @ mail.domaine.fr 10

L'idéal étant d'avoir des enregistrements DNS différents pour les accès publics et pour les accès privés. Je m'explique. Quand l'accès provient de l'extérieur, on fera en sorte de résoudre sur l'adresse IP publique sur laquelle est joignable votre serveur Exchange (à moins que vous utilisiez un service tiers pour l'analyse des e-mails), tandis pour que quand l'accès provient de l'intérieur (exemple : un PC avec Outlook connecté au réseau local), on fera en sorte de faire la résolution de noms avec l'adresse IP privée.

Avec PowerShell, vous pouvez vérifier les enregistrements DNS :

Resolve-DnsName -Type A mail.domaine.fr | ft -AutoSize
Resolve-DnsName -Type MX domaine.fr | ft -AutoSize
  • Le futur serveur Exchange doit être membre du domaine Active Directory
Add-Computer -DomainName domaine.local
  • Les contrôleurs de domaine Active Directory de la forêt doivent exécuter Windows Server 2012 R2 au minimum
  • La forêt Active Directory doit avoir un niveau fonctionnel en "Windows Server 2012 R2" au minimum
Get-ADForest | fl Name,ForestMode
  • Microsoft Outlook 2013 au minimum, que ce soit sur Windows ou macOS, afin d'être compatible Exchange 2019

Il y a également des composants et fonctionnalités de Windows Server à installer sur le serveur de messagerie avant de lancer l'installation de Microsoft Exchange. Ce sont, en quelque sorte, des prérequis. Nous allons voir quels sont ces éléments et comment les installer dans l'étape suivante.

Pour des détails supplémentaires sur les prérequis, consultez cette documentation :

III. Préparer le futur serveur de messagerie

Sur le serveur de messagerie sur lequel Microsoft Exchange 2019 va être installé, nous devons installer certains composants. Voici les étapes à réaliser.

A. Installer .NET Framework 4.8

Le premier composant à installer, c'est .NET Framework 4.8. Toutefois, sur Windows Server 2022 il est déjà installé donc c'est inutile d'essayer de l'installer à nouveau. Au cas où vous l'auriez supprimé, voici le lien :

B. Installer Visual C++ Redistributable Package

Vous devez installer sur le serveur Visual C++ Redistributable Package pour Visual Studio 2012 et Visual Studio 2013. Voici les liens de téléchargements :

C. Installer UCM API 4.0

Vous devez installer le runtime "Unified Communications Managed API 4.0" sur le serveur également. Le téléchargement s'effectue aussi depuis le site Microsoft, via ce lien :

D. Installer des composants de Windows Server

Microsoft Exchange a besoin de nombreux composants de Windows Server. Pour les installer, le plus simple est d'utiliser une console PowerShell et d'exécuter la commande "Install-WindowsFeature" avec la liste des fonctionnalités à installer. Par exemple, il y a des consoles d'administration ainsi que des fonctionnalités propres à IIS (serveur Web pour le Webmail Exchange).

Personnellement, je préfère réaliser toutes les étapes préparatoires avant d'installer Exchange, mais sachez que celle-ci peut être réalisée pendant l'installation d'Exchange, car c'est proposé par l'assistant.

Voici la commande à exécuter sur un serveur Windows Server avec une interface graphique :

Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

Sur un Server Core, la liste est légèrement différente. Voici la commande à exécuter :

Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Metabase, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, RSAT-ADDS

L'installation prend quelques minutes... Un peu de patience. Il n'est pas nécessaire de redémarrer le serveur à la fin de l'installation.

Exchange - Prérequis composants Windows Server

E. Installation d'URL Rewrite pour IIS

Avant-dernière étape de préparation : l'installation du module "URL Rewrite 2.1" pour IIS. Le Webmail d'Exchange a besoin de ce composant pour fonctionner. Il suffit de télécharger le package d'installation et d'installer le module en quelques clics.

Exchange 2019 - Installation URL Rewrite

Pour le téléchargement, c'est par ici :

F. Installer les dernières mises à jour du système

Vous devez installer les dernières mises à jour cumulatives sur votre serveur avant de procéder à l'installation de Microsoft Exchange. Un tour dans Windows Update suffira pour lancer une recherche de mises à jour.

Exchange - Mise à jour Windows avant installation

IV. Installation de Microsoft Exchange 2019

Avant de continuer : connectez-vous sur votre serveur Exchange avec un compte "Administrateur du domaine". Je vous recommande aussi de redémarrer le serveur avant de procéder à l'installation (au cas où un reboot serait en attente suite à une mise à jour, par exemple).

Pour réaliser l'installation de Microsoft Exchange 2019, vous devez télécharger les sources. Utilisez un site officiel de Microsoft pour réaliser cette action. Voici un lien :

L'ISO d'installation de Microsoft Exchange 2019 pèse environ 5,8 Go. Pour ce tutoriel, j'utilise l'image ISO suivante : "Exchange Server 2019 Cumulative Update 12".

Commencer par monter l'image ISO via un double-clic. Accédez à l'image disque. Exécutez le "setup" en tant qu'administrateur via un clic droit "Exécuter en tant qu'administrateur".

Installer Exchange Server 2019 - Image ISO

Choisissez "Connect to the internet and check for updates" lorsque la première étape s'affiche. L'objectif étant de vérifier s'il y a une mise à jour plus récente. À ce jour, c'est non, car c'est la version la plus récente.

Installer Exchange Server 2019 - Etape 1 - Check for updates

Poursuivez. L'étape "Copying files" apparaît : patientez pendant la copie des fichiers.

Installer Exchange Server 2019 - Etape Copying Files

Une fois que c'est fait, l'étape "Introduction" apparaît. Poursuivez.

Acceptez la licence (première ou deuxième option) et continuez.

Installer Exchange Server 2019 - Etape Accepter la licence

Cochez l'option "Use recommended settings" pour utiliser les paramètres d'installation recommandés. Pour tout configurer, partez sur la seconde option.

Installer Exchange Server 2019 - Etape Paramètres recommandés

Au moment de choisir les rôles, sélectionnez "Mailbox role", car il s'agit du premier serveur de notre environnement Exchange. L'option "Automatically install Windows Server roles and features that are required to install Exchange Server" n'est pas nécessaire, car nous avons déjà installé les différents rôles avec la commande PowerShell exécutée lors de la préparation du serveur.

Installer Exchange Server 2019 - Etape Sélection des rôles

Exchange Server en lui-même va s'installer dans "C:" et nécessite 5,7 Go d'espace disque.

Installer Exchange Server 2019 - Etape Emplacement installation

Nommez l'organisation Exchange, ce qui sera probablement le nom de votre entreprise. L'option "Apply Active Directory split permissions security model to the Exchange organization" est nécessaire principalement avec des services informatiques où il y a une répartition des rôles . Par exemple, si la personne qui administre l'Active Directory n'est pas la même que celle qui gère l'Exchange.

Installer Exchange Server 2019 - Etape Nom organisation

Laissez cette option sur "No" pour que la protection anti-malware reste active. Ici, on vous propose de la désactiver. Cela peut s'avérer utile si vous avez déjà une autre solution qui effectue ce travail à la place d'Exchange.

Installer Exchange Server 2019 - Etape Malware Protection

Avant de lancer l'installation, le setup vérifie si vous respectez les différents prérequis...

Installer Exchange Server 2019 - Etape vérification des prérequis

Normalement, vous devez avoir uniquement 2 warnings : l'installeur d'Exchange vous informe qu'il va procéder à la préparation de l'annuaire Active Directory, ce qui implique notamment de mettre à jour le schéma Active Directory. Cliquez sur "Install" pour lancer l'installation d'Exchange Server 2019 !

Installer Exchange Server 2019 - Etape de lancement de l'installation

Patientez pendant l'installation... Elle dure au moins 30 minutes... Et la durée dépend des performances de votre machine. Pas de panique, donc.

Installer Exchange Server 2019 - Etape installation en cours

Félicitations, vous venez d'installer Microsoft Exchange Server 2019 ! Maintenant, il faut redémarrer le serveur !

Installer Exchange Server 2019 - Setup Completed

Suite à l'installation, une nouvelle OU est visible à la racine de l'Active Directory. Nommée "Microsoft Exchange Security Groups", elle contient les groupes d'administration suivants :

Groupes de sécurité créés par Exchange

V. Première utilisation d'Exchange

A. Centre d'administration Exchange et Exchange Management Shell

L'administration d'Exchange s'effectue au travers d'un portail d'administration en mode Web, ainsi que de commandes PowerShell. Le portail d'administration appelé "Centre d'administration Exchange" est accessible à cette adresse :

# En local sur le serveur
https://localhost/ecp

# À partir d'une machine du réseau local (via le nom du serveur)
https://az-exchange/ecp

# À partir de l'extérieur
https://mail.domaine.fr/ecp

Sur cette interface, vous pouvez vous authentifier avec un compte administrateur du domaine.

Première connexion au centre d'administration Exchange

Le Centre d'administration Exchange est l'endroit idéal pour gérer la configuration de votre serveur : gérer les flux de courriers, les groupes, les boîtes aux lettres, les boîtes aux lettres partagées, les stratégies d'accès, les certificats, les domaines, etc...

Remarque : dans un prochain article, nous verrons comment restreindre l'accès au Centre d'administration Exchange. Mais, par défaut, cette interface est accessible depuis l'extérieur (Internet).

En complément, il y a l'Exchange Management Shell qui contient des commandes PowerShell pour gérer Exchange. Des raccourcis sont disponibles dans le menu Démarrer du serveur.

Exchange Management Shell - Exchange 2019

B. Webmail d'Exchange Server 2019

En ce qui concerne les utilisateurs, ils ont le choix entre un client de messagerie type Outlook, ou un accès via le webmail. Ce dernier étant accessible à l'adresse suivante (c'est mieux d'avoir une seule adresse en interne et en externe) :

https://mail.domaine.fr/owa

Le sigle "OWA" fait référence à Outlook Web Access. L'utilisateur doit se connecter avec ses identifiants Active Directory (au préalable, vous devez créer la BAL).

Microsoft Exchange Server - Accès à OWA

Ah, mon utilisateur à bien reçu l'e-mail de test que je lui ai envoyé ! Si cela ne fonctionne pas, vérifiez vos enregistrements DNS, les règles de pare-feu (notamment le pare-feu en sortie de réseau) ainsi que l'adresse e-mail utilisée.

Premier e-mail reçu sur Exchange

C. Déplacer la base de données Exchange

Suite à l'installation de Microsoft Exchange, la base de données (au format EDB) et les journaux sont stockés à l'emplacement par défaut aux côtés des binaires d'Exchange :

C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 0780012571\Mailbox Database 0780012571.edb

Vous pouvez déplacer la base de données Exchange sur un autre volume, ainsi que les logs sur un volume différent (soit 3 volumes au total). A minima, utilisez un volume séparé pour stocker la base de données et les journaux. Nous venons d'installer notre serveur Exchange, donc c'est aisé et rapide de déplacer les données maintenant.

L'objectif va être de déplacer la base de données et les journaux vers le volume ReFS, au chemin suivant :

E:\MsExchange_DB\

Nous allons en profiter pour renommer la base de données, car "Mailbox Database 0780012571.edb" n'est pas un nom très parlant... Ouvrez l'Exchange Management Shell.

Note : les bases de données Exchange sont visibles dans le Centre d'administration, dans : serveurs > bases de données.

Cette première commande définit le nom "Mailbox IT-Connect" pour la base de données (à la place du nom mentionné précédemment).

Get-MailboxDatabase "Mailbox Database 0780012571" | Set-MailboxDatabase -Name "Mailbox IT-Connect"

La commande "Get-MailboxDatabase" permettra de vérifier l'opération puisqu'elle sert à lister les bases.

Dès que c'est fait, on enchaîne avec la commande "Move-DatabasePath" pour déplacer la base de données (-EdbFilePath) et les journaux (-LogFolderPath). Ce qui donne :

Move-DatabasePath "Mailbox IT-Connect" -EdbFilePath "E:\MsExchange_DB\MailboxITConnect.edb" -LogFolderPath "E:\MsExchange_DB\Logs\"

Quelques secondes plus tard, le tour est joué (attention, pendant l'opération la base de données est démontée et donc inutilisable) :

Déplacer base de données Exchange 2019

D. Créer une nouvelle boite aux lettres Exchange

Pour créer une boîte aux lettres (appelée aussi "BAL") pour un utilisateur, vous devez suivre ce chemin : destinataire > boîtes aux lettres > "+". Ici, vous devez renseigner un formulaire : soit vous sélectionnez un utilisateur existant dans votre annuaire Active Directory, soit vous créez l'utilisateur en même temps. Gardez à l'esprit que les comptes utilisateurs et les boîtes aux lettres Exchanges sont liés. À tel point que si vous supprimez une boîte aux lettres dans Exchange, l'utilisateur AD correspondant sera supprimé !

Créer une boite aux lettres Exchange 2019

Si votre Exchange est mis en place sur un domaine Active Directory avec un domaine non routable (exemple ".local" ou ".lan"), le domaine de l'adresse e-mail ne correspondra pas à votre domaine de messagerie pour communiquer avec l'extérieur.

Dans ce cas, vous devez déclarer un nouveau domaine dans Exchange puis l'attribuer dans une politique d'adresses e-mails.

  • Pour ajouter le domaine 

1 - Cliquez sur "Flux de courrier" (Mail flow)

2 - Cliquez sur l'onglet "Domaines acceptés"

3 - Ajoutez un nouveau domaine de messagerie avec l'option "Le domaine accepté fait autorité"

4 - Validez

5 - Editez le domaine pour cocher l'option "Définir ce domaine comme domaine par défaut."

  • Pour éditer la stratégie d'adresse de courrier

Soit il faut modifier la stratégie par défaut (qui s'applique sur tous les éléments) ou créer une nouvelle stratégie.

1 - Cliquez sur "Flux de courrier" (Mail flow)

2 - Cliquez sur l'onglet "Stratégies d'adresses de courrier"

3 - Editez la "Default Policy"

4 - Cliquez sur "Format de l'adresse de courrier" et modifiez le domaine de "SMTP" pour que ça corresponde au nouveau domaine

Exchange 2019 - Modifier stratégie adresse de courrier

5 - Validez

Une fois que c'est fait, vous pouvez créer votre boite aux lettres : par défaut, elle bénéficiera d'une adresse e-mail principale en "@domaine.fr".

Pour que l'identifiant de l'utilisateur (d'un point de vue Active Directory) hérite aussi de ce domaine de messagerie (ce qui est idéal), vous devez déclarer un nouveau suffixe UPN dans votre annuaire Active Directory.

VI. Conclusion

Voilà, votre serveur de messagerie Exchange est en place ! Bien que la configuration ne s'arrête pas là pour qu'il soit prêt à la production (Exchange est un sujet conséquent), la première grosse étape d'installation est terminée, et en soit, il est utilisable !

Pensez à maintenir à jour votre serveur Exchange : pas seulement au niveau du système Windows Server, mais aussi au niveau de l'applicatif en lui-même. En effet, Microsoft met en ligne des mises à jour Exchange par l'intermédiaire de "Cumulative Update" appelée aussi "CU". Il est important de procéder à l'installation pour bénéficier des derniers correctifs de sécurité.

L'article Installation pas à pas de Microsoft Exchange 2019 sur Windows Server 2022 est disponible sur IT-Connect : IT-Connect.
❌