Nous ne pouvons pas parler de messagerie sans parler de sécurité. Notre organisation Exchange a même besoin d’être sécurisée pour être fonctionnelle !
Dans cet article, nous allons donc étudier de près les certificats ainsi que la tolérance de panne : tout cela en ligne de commande avec Windows PowerShell bien évidemment !
Parfois, configurer la sécurité du serveur gérant les accès clients (rôle CAS) est un véritable challenge. Quoiqu’il en soit, c’est une étape importante pour sécuriser l’ensemble des communications externes ! Pour chiffrer les communications, le serveur CAS utilise Secure Sockets Layer (SSL) qui requiert l’utilisation d’un certificat.
Les clients de messagerie doivent faire confiance à l’autorité de certification qui a généré le certificat. Il existe trois types de certificats : Voir Tableau 1 Nativement, Exchange utilise des certificats auto-signés pour sécuriser les communications. Si un client de messagerie accède au serveur CAS depuis l’extérieur, il est nécessaire de changer ce certificat par un certificat issu d’une autorité de certification de confiance.
De plus, les certificats auto-signés ne peuvent pas être utilisés avec Outlook Anywhere. Afin de mettre en place un certificat, il est important de respecter le processus suivant :
1- Générer le certificat
Evidemment, PowerShell est là pour nous aider grâce à la Cmdlet « New- Exchange Certificate » ! Sans paramètre, cette Cmdlet génère un certificat auto-signé qui expire au bout d’une année. Sur notre serveur CAS, pour générer un certificat valide pour plusieurs noms DNS (type de certificat le plus utilisé !) nous ferons donc ainsi : New-ExchangeCertificate ` –GenerateRequest :$true ` –FriendlyName ContosoCert ` –PrivateKeyExportable:$true ` –Path ‘c:\temp\CertRequest.req’ ` –SubjectName ‘C=FR, S=Ile de France, L=Paris, O=Contoso,OU=IT, CN=webmail.contoso.com’ ` –DomainName webmail.contoso.com,autodiscover.contoso.com
Dans cet exemple, les utilisateurs accèderont à leur messagerie avec OWA par l’URL « webmail.contoso.com ». L’autodiscover permettra aux clients Outlook 2007 de se configurer automatiquement de manière sécurisée par ce certificat.
2 – Obtenir le certificat
L’obtention du certificat dépend de l’autorité de certification que l’on souhaite utiliser ! Dans le cas où nous avons une autorité de certification racine de confiance dans notre entreprise, nous pouvons lui soumettre le fichier généré dans l’étape précédente. Notre certificat nous sera alors délivré. Il est aussi possible d’acheter un certificat à une autorité de certification publique comme VeriSign.
3 – Importer le certificat
Dans cette étape, nous allons importer le certificat obtenu sur la même machine qui a fait la requête car la sécurité du certificat est liée à la machine qui l’a généré ! Si nous importons notre certificat sur une autre machine, nous n’aurons pas la clé privée. Sur notre serveur CAS nous allons donc utiliser à nouveau notre outil en ligne de commande :
Import-ExchangeCertificate –Path c:\temp\CertRequest.req Sachez qu’il existe une Cmdlet pour supprimer un certificat importé en cas d’erreur : « Remove-ExchangeCertificate » !
4- Activer le certificat
Cette avant dernière étape lie le certificat à un service Exchange. Pour cela et comme d’habitude, une Cmdlet fait le travail : « Enable-ExchangeCertificate ». Elle prend en paramètre l’identifiant unique du certificat à activer que nous pouvons obtenir via la Cmdlet « Get-ExchangeCertificate » et le service Exchange auquel lier le certificat. Par Exemple : Enable-ExchangeCertificate ` –Thumbprint A7810FE86C10091EB8A764B5430CC7681ABBA410 ` -Services IIS
5 – Copier le certificat
Lorsque dans une organisation Exchange il y a plusieurs serveurs CAS ou bien un serveur ISA chargé de publier les services Exchange, il est nécessaire d’importer le certificat sur ces machines. Pour cela, nous devons dans un premier temps l’exporter avec la console MMC au format PFX incluant la clé privée puis l’importer sur les autres machines: Import-ExchangeCertificate –Path c:\temp\CASCert.pfx ` -Password (Get-Credential).Password
Dans l’exemple, le mot de passe de la clé privée sera demandé interactivement. Rien de vraiment compliqué !
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.
