Reprise du message précédent :
c'est bien ce que je pensais, pas de serveur exchange en dmz.
 
Le besoin d'accès depuis l'extérieur se fait via OWA, peut etre outlook je verrai ca cette semaine.
 
Donc si je comprends bien il est possible d'avoir exchange à l'interieur du reseau et en dmz je met un serveur tier.
 
Quels sont les ports à ouvrir dans ce cas entre dmz et réseau interne ? et entre dmz et extérieur.
 
Pour info le presta a mis en plus un IMSS (InterScan Messaging Security Suite) pour l'antispam.
 
Quand tu parles de reverse proxy ce serait plutot directement entre exterieur et exchange ?
Visiblement ce qui pose problème est le passage par le point dmz. Je pensais que dans la version 2010 il y avait ce type de role avec le serveur CAS pour mettre un serveur en DMZ et ne pas exposer le serveur exchange.
 
Merci pour ta réponse, je cherche dans les doc microsoft mais je ne trouve pas mon cas et je découvre exchange donc les termes me sont pour beaucoup étrangés. tous ces roles m'embrouilles et quand je cherche les ports je retombe souvent sur du RPC port dynamique (pas facile à traduire en iptables :-D)

Non le rôle CAS (Client Access Server) c'est l'interface entre ton backend (les mailbox) et tes clients via divers protocoles : OWA, POP, IMAP, RPC, RPCoHTTP (Outlook Anywhere), Web Services.
Tout comme le rôle HUB est l'interface SMTP entre ton backend et les autres serveurs SMTP.

Ces 2 rôles sont une sorte de front tier/middle tier dans une interface 3tiers.
Ca publie les services sur tes clients internes.

Note que l'ensemble des rôles peuvent être sur la meme machine (sauf le role Edge qui lui est DMZ donc sur une machine isolée)

Si tu veux publier tes services à l'extérieur, soit tu forwardes les ports (non recommandé mais faisable), soit tu rajoutes une couche.
Pour le protocole HTTP/HTTPS ça passe par un reverse proxy
Pour le POP/IMAP/SMTP par des gateway mail.
Pour le SIP (si tu fais de l'UM) via une passerelle.

Donc en DMZ tu mets un reverse proxy pour permettre à tes clients OWA d'accéder à la messagerie.
MS recommande ses produits bien entendu mais tu peux le faire avec d'autres (SQUID, Apache, etc.). A voir si tous sont compatibles (j'ai pas réussi à faire marcher Apache pour Outlook anywhere à l'époque). L'avantage de TMG ou UAG c'est que l'authentification est faite par ce produit et donc tu casses le flux au niveau de la passerelle.

Du coup pour la partie accès client OWA, tu as un flux : HTTPS à faire passer entre internet et ta dmz et un flux entre ta dmz et ton exchange : https aussi.

Je pense vraiment que ce qui convient notre infra de secu c'est ce que tu exposes avec tmg ou uag. Au moins un seul port a ouvrir entre DMZ et interne.
Un peu comme les broker citrix ou vmware.
 
Je me demande (car je n'en ai pas encore vu) comment sont exposés les exchanges dans les organisations pro (hors labo).
D'un autre coté je n'ai pas encore bien compris ce que proposait le presta et quel est le besoin final. Je sais que ca se complique de jour en jour avec un microsoft CRM et un sharepoint a exposé. Je sens que mon parefeu va pas aimer tous ces flux crosoft :-D
 
Merci pour les infos. si un simple reverse proxy suffit, je pense que nginx pourra répondre au beosin (je l'espere en tout cas).
Si j’accouche d'un modèle de conf, je ferais un retour.

http://planetit.ws/linux/debian/co [...] r-owa.html pour nginx. Pour Exchange 2010 rajoute /ecp en plus de /owa (et vire Microsoft-ActiveSync si tu veux pas publier activesync pour une synchro avec les mobiles). Rajoute aussi /autodiscover tant qu'à faire.

Pour sharepoint c'est faisable aussi via un reverse proxy. Pour CRM jamais fait mais ça doit se faire.

TMG crée facilement les règles qui vont bien pour Exchange et Sharepoint mais par contre ça a un cout. TMG c'est un proxy/reverse proxy/firewall en fait.

Pour ton Exchange, 443 seulement, que ce soit pour owa ou rpcoverhttps.
Dans ce dernier cas, un certificats émanant d'une autorité de certification reconnue est indispensable.
Si c'est que pour owa, tu peux le générer toi meme, t'auras juste une alerte de sécurité dans le navigateur.

mon premier test avec nginx est plutôt positif, j'accède bien au serveur exchange via owa.
j'ai encore un problème de certificat, l'existant n'est pas très conforme et FF me refuse la connexion.
Par contre avec IE ou chrome pas de soucis (j'indique de continuer, je comprends les risques et ça passe).
 
Il me reste à régler mes problèmes de sortie de message : reconfiguration de mes sécurités pour renvoyer exchange vers IMSS qui est en DMZ.
 
Puis à faire ces mêmes tests nginx pour l'accès sharepoint.
 
J'ai demandé au prestataire de regarder les solutions sharepoint (l'établissement a des licences MSDNA donc les couts de licence sont défiant toute concurrence :-D )
 
Merci pour votre aide qui m'a été bien précieuse pour éclaircir mon problème.

Pour OWA le certificat c'est pas un gros problème, meme sous FF ca peut passer.  
C'est juste "crado" pour les users, et si ils ont une navigateur "chiant", ca peut etre "compliqué" pour eux