sy/va:n coudev://e

Les bases d’une bonne configuration Exchange – Partie 1

Sylvain COUDEVILLE
Les bases d'une bonne configuration Exchange (Tutorial)

Les bases d’une bonne configuration Exchange – Partie 1

Ce tutoriel est en 4 parties:
– Partie 1
– Partie 2
– Partie 3
– Partie 4

J’interviens depuis quelques temps sur les Forums Technet, et j’ai pu constater un nombre important de questions et de problèmes dûs à une configuration Exchange “par défaut” voire très aléatoire…

Ce tutoriel a pour but de faire une check-list des besoins, et des commandes importantes pour une installation Exchange correcte (je n’aurai pas la prétention de dire qu’elle sera parfaite, mais elle sera fonctionnelle !).

La première partie de cet article fera l’état des prérequis que vous devrez réunir pour effectuer une installation dans les règles.
La seconde partie détaillera l’installation d’un Exchange en mono-serveur, et le paramétrage de base pour envoyer et recevoir des emails en interne.
Dans la troisième partie, nous nous pencherons sur le paramétrage Externe, afin que votre Exchange puisse envoyer et recevoir des emails via Internet.
La quatrième partie sera consacrée au paramétrage de la fonctionnalité que tout le monde cherche à avoir : Outlook Anywhere ou “comment synchroniser son Outlook même à l’extérieur de l’entreprise” !

Première partie – Les Prérequis pour un Exchange sans soucis


Pour réussir votre installation d’Exchange, il vous faut :

Avant de vous lancer dans l’achat de tout cela, lisez les lignes ci-dessous afin de comprendre et d’acheter ce dont vous avez vraiment besoin !

DVD et licences Windows Server / Exchange

On en parle rarement dans les blogs, mais c’est quand même la base !

Pour une installation réussie, vous devrez dédier une machine (ou une VM) à Exchange. Pour cela, il vous faudra une licence Windows Server (bien entendu, vous pouvez utiliser des évaluations de Windows Server et Exchange pour vos tests, mais vous devrez leur installer une vraie licence si vous passez cette machine en production).

Toutes les informations sur le licensing Microsoft Exchange ici : https://products.office.com/fr-fr/exchange/microsoft-exchange-licensing-faq-email-for-business.

Pour télécharger les versions d’évaluation de Windows Server et Exchange, c’est ici :

IP Publique et redirection de port

De quoi s’agit-il ?

J’ai vu souvent sur les blogs Technet, des Admin (système) que prennent possession d’une infrastructure avec les mails hébergés chez un hébergeur lambda (OVH, Amen, Orange, etc.) sur des boîtes en POP/IMAP.
Ils décident d’installer un Exchange dans l’entreprise pour améliorer les condition de travail de leurs utilisateurs (en ajoutant les fonctionnalités de Partage, Synchro Smartphone etc.), cependant, le flux de messagerie est un peu une énigme pour eux.

Donc, voici un petit schéma pour résumer les flux de messagerie lorsqu’une entreprise décide d’héberger son propre serveur de messagerie (comme Exchange) :

On voit dans ce schémas 3 flux :

Ceci induit une chose importante : pour que les utilisateurs sur Internet puissent communiquer avec votre serveur Exchange, il vous faut une adresse IP publique sur votre accès Internet :

En effet, sur votre réseau local, vous êtes habitués à travailler avec des IP privées (192.168.x.y ; 172.16.x.y ; 10.x.y.z). Ces adresses ne sont pas accessibles sur Internet (voir http://fr.wikipedia.org/wiki/Adresse_IP#Utilisation_des_adresses_IP).

Lorsque l’on veut communiquer avec Internet, ce sont les IP publiques qui sont utilisées.

Il en existe 2 types :

Sans IP fixe, les utilisateurs sur Internet ne peuvent pas trouver votre serveur (c’est comme s’il déménageait toutes les 24 heures).

Avant Exchange, les utilisateurs allaient chercher leur courrier en POP ou en IMAP sur un serveur hébergé à l’extérieur : maintenant, c’est la planète entière qui vient vous distribuer votre courrier directement sur votre serveur de messagerie !

Du coup, il faudra mettre les mains dans le routeur/firewall de l’entreprise afin de rediriger ces fameux ports 25 et 443 (protocole TCP) vers le port 25 et 443 du serveur Exchange.

Et il va donc falloir aussi les protéger ces ports puisque la planète entière pourra potentiellement se connecter dessus.

Protection antispam et IDS/IPS

Les ports 25 et 443 sont ouverts : du coup, votre serveur Exchange est potentiellement exposé à de multiples attaques.

Tout d’abord, il faut le protéger de ces attaques. Pour cela, vous devrez activer les fonctionnalités d’IDS/IPS de votre routeur (IDS : Intrusion Detection System ; IPS : Intrusion Protection System).
Ces fonctionnalités (qui peuvent avoir des noms différents suivant la marque de votre Firewall) servent à vérifier le contenu des paquets qui sont présentés à vos serveurs, afin de repérer d’éventuelles tentatives d’attaques (exploitation de failles de sécurité connues, Déni de Service (DoS), etc.). Plus d’infos : http://fr.wikipedia.org/wiki/Système_de_prévention_d’intrusion.

Après cela, il va falloir protéger vos utilisateurs de ce port ouvert au monde : en effet, le monde entier peut contacter votre serveur Exchange, les spammeurs vont donc s’en donner à cœur joie !
Vous devrez donc installer une protection antispam.

Je vous recommande une double protection :

Le nom de domaine publique

Cela peut être évident pour certaines personnes, mais pas forcément pour tous!

Vous utilisiez des boîtes aux lettres @orange.fr ou @gmail.com : vous ne pouvez pas utiliser Orange.fr ou Gmail.com sur votre serveur Exchange car ce domaine ne vous appartient pas.

Vous devez donc choisir (si vous n’en n’avez pas déjà un) un nom de domaine, et le payer chez un hébergeur (OVH, Amen, etc.).

Une fois en votre possession, ce nom de domaine vous permettra de communiquer par email avec des adresses @mondomaine.fr.

Attention ! Le nom de domaine Internet n’a rien à voir avec le nom de domaine Active Directory. Le nom de domaine Active Directory ne vous confère aucun droit sur Internet. Par exemple, si vous avez créé un AD avec comme nom de domaine “toto.fr”, cela ne vous permet par d’utiliser “toto.fr” sur Internet.
Vous devez faire l’acquisition de “toto.fr” chez un hébergeur pour que ce domaine puisse être utilisé sur  la toile.

Avant de vous inquiéter : si vous avez créé un Active Directory avec “toto.fr” et que “toto.fr” n’est pas disponible sur Internet, rien ne vous empêchera d’acquérir “toto-sarl.fr” et de configurer Exchange avec. Cela n’aura pas d’impact sur votre AD.
De la même manière, si votre AD utilise un domaine non-routable sur Internet, comme “mondomaine.local”, cela ne bloquera pas le fonctionnement d’Exchange.

Un certificat acheté auprès d’une autorité de certification

Et voila qu’il nous demande encore de passer à la caisse !
Oui, ou non. Ça dépend de si vous aimez travailler ou pas… 🙂

Pour vos tests, Symantec vous propose un certificat en évaluation 30 jours gratuitement. Votre maquette ne vous coutera donc pas très cher.

Ensuite, pour la production, vous devrez acheter votre certificat. D’autres personnes vous diront que vous n’avez qu’à utiliser un certificat auto-signé… Je vais donc vous expliquer pourquoi il vaut mieux éviter.

Un certificat, c’est quoi ?

Déjà, on va essayer de comprendre de quoi il s’agit, car c’est un gros sujet.

Si ce n’est pas très clair, regardez l’article sur Wikipedia : http://fr.wikipedia.org/wiki/Certificat_électronique.

Un certificat, c’est un document numérique en 2 parties, voué à chiffrer les données entre un client et un serveur.

Lorsque vous vous connectez à votre banque, vous le faites par le protocole HTTPS (https://www.mabanque.fr). Le ‘S’ signifie ‘Sécurisé’, car la communication entre votre poste et le serveur de la banque est chiffrée.

Cela fonctionne grâce à un algorithme de chiffrement nommé RSA, et qui se base sur un système de clé publique et clé privée.

Pour faire simple, celui qui possède la clé privée peut déchiffrer les messages. Ceux qui possèdent la clé publique peuvent chiffrer les messages.

Concrètement, lorsque vous vous connectez à votre banque, le serveur de la banque vous envoie sa clé publique. Vous chiffrez les informations avec cette clé publique, vous envoyez les données, et le serveur de la banque est le seul à pouvoir les déchiffrer.

La communication inverse fonctionne de la même manière : vous envoyez VOTRE clé publique au serveur de la banque, la banque chiffre les données, et les envoies. Vous déchiffrez les données avec VOTRE clé privée.

C’est automatique, vous ne voyez rien passer… SAUF lorsque le certificat du site que vous tentez de joindre n’est pas valide !

Le certificat, c’est ce que vous envoie le site que vous contactez, il contient plusieurs informations :

Pour qu’une communication puisse se faire convenablement, il faut que TOUTES ces informations soient valides.

Si le certificat expire le 01/01/2014 et que l’on est le 02/01/2015 : ERREUR !

Si le certificat est généré pour ‘mail.mondomaine.fr’ + ‘owa.mondomaine.fr’ et que le serveur que vous contactez s’appelle ‘autodiscover.mondomaine.fr’ ou ‘mail.mondomaine.com’: ERREUR !
etc.

Regardons maintenant la signature : de quoi s’agit-il ?

N’importe qui peut générer un certificat, il suffit juste d’avoir les outils adéquats. D’ailleurs, Exchange génère automatiquement un certificat pendant son installation. Mais comment faire confiance à un certificat ?
En effet, si je le souhaitais, je pourrais générer un certificat ‘www.mabanque.fr’, l’installer sur le serveur de mon blog et tenter de vous faire croire que mon site “sylvaincoudeville.fr” s’appelle “mabanque.fr” ?

Pas vraiment, car lorsque l’on fabrique un certificat dans son “garage”, il s’agit d’un certificat auto-signé, c’est à dire, qui n’est pas signé par une autorité de certification, mais par moi-même.

Du coup, si j’essaye de vous tromper, voici ce que vous aurez :

Une autorité de certification a pour travail de s’assurer qu’ils délivrent un certificat à une personne autorisée. Si je contacte Symantec pour leur demander un certificat pour “mabanque.fr”, il faut s’assurer que je suis le propriétaire du domaine “mabanque.fr” : si ce n’est pas le cas, il ne me délivreront pas le certificat.

Si je leur demande un certificat pour “sylvaincoudeville.fr”, il verront que ce domaine m’appartient, me délivreront un certificat pour ce domaine et mettront dessus un “tampon” Symantec afin de certifier que le certificat est vérifié :

On voit même le chemin de certification : OVH est vérifié par Symantec, qui est vérifié par Verisign.

La signature, c’est le tampon qui est mit par une autorité de certificat sur un certificat.

L’avantage d’un certificat signé par une Autorité de Certification est que ce certificat apparaitra partout comme étant valide (car les smartphones, PC, Mac etc. partagent la liste des autorités de certification valides sur Internet).

Certificat auto-signé

Un certificat auto-signé, c’est ce que vous fournit Exchange à la fin de l’installation.

Comme indiqué plus haut, ce certificat et signé par vous-même. Il n’est donc valide que pour vous-même.

Vous pouvez utiliser un tel certificat, cependant, vous devrez installer ce certificat sur chacun des périphériques qui devront se connecter à votre serveur Exchange afin de “forcer” ce certificat comme étant valide auprès de la machine.

“Vrai” certificat

Le certificat signé par une autorité de certification sera détecté automatiquement comme étant valide. Ce genre de certificat sera donc prêt à l’emploi sans aucune manipulation sur les postes de travail, smartphones etc.

Le comparatif

Le match “Auto-Signé” / “Autorité de certification” :

Auto-signé
Signé par Autorité de certification

Grauit

Entre 30 et 80€ par an

Délivré en 5 minutes

Délivré en moins de 24 heures

A déclarer sur les périphériques

Aucune configuration sur les périphérique

Faites votre choix ! Mais rappelez-vous, un certificat auto-signé devra être installé sur chacun des périphériques pour être géré convenablement.

Certes, il est toujours possible de faire cela avec des GPO, mais comment ferez-vous avec les Smartphones personnels de vos utilisateurs ? …

Et un certificat bien acheté et avec un bon conseil comme chez SNSV Consulting, ça commence à moins de 20 € par an : pourquoi s’en priver?
Et avec le code promo FIRSTCERT15, 15% de réduction sur votre premier Certificat SSL!

Dans la seconde partie, nous verrons l’installation de base d’Exchange et le paramétrage pour envoyer et recevoir des mails en interne.

Quitter la version mobile