Publication OWA via une array TMG membre d’un domaine en DMZ
Nous allons dans cet article décrire comment fonctionne TMG pour publier l’URL externe de votre OWA et vous indiquer quels types de certificats utiliser. Le site OWA est installé sur les serveurs CAS de votre infrastructure Exchange. L’URL interne du site est enregistrée dans votre DNS interne et est accédé par les clients membres de votre domaine. L’URL externe du site est enregistrée dans votre DNS externe et est accédée par les clients se connectant depuis l’internet qui ne sont pas forcément membres de votre domaine. Pour obtenir ces URLs, lancer la commande suivante via l’Exchange Management Shell:
Get-OwaVirtualDirectory | ft server,InternalURL,externalURL |
Dans notre exemple l’URL interne est mail.internal.ldap389.info et l’externe mail.ldap389.info. Seul le trafic SSL est accepté, sur chacun de nos CAS un certificat SAN issu de notre PKI d’entreprise avec ces deux URLs est mis en place.
Les clients accédant à l’URL interne mail.internal.ldap389.info se connectent directement au serveur CAS, le trafic est réparti entre les différents membres du CAS array via un équipement HLB (trafic en vert dans le schéma ci-dessous).
Les clients se connectant depuis l’internet via l’URL mail.ldap389.info accèdent tout d’abord aux serveurs TMG, le trafic est réparti sur les cartes réseau externes des différents membres de l’array TMG via un équipement HLB, ces IPs sont accessibles depuis Internet et situés dans une “DMZ publique”. Le trafic entre les clients internet et le CAS array est indiqué en rouge sur le schéma et expliqué ci-après:
Un certificat a été acheté auprès d’un CA externe et déclaré sur le listener OWA des serveurs TMG afin de permettre aux machines ne faisant pas partie du domaine internal.ldap389.info, de communiquer via SSL avec votre array TMG. Si vous utilisez un certificat issu de votre PKI interne alors le root CA devra être déclaré comme de confiance sur tous les clients externes, sous peine d’avoir ce type d’avertissement lors de la connexion:
Les serveurs TMG communiquent, à partir de leur carte réseau interne situé en “DMZ privée”, de manière sécurisé avec le CAS array. Pour cela le certificat de votre CA d’entreprise est déclaré comme autorité de certification de confiance sur les serveurs TMG. Ceci afin de permettre le traffic SSL avec le certificat SAN mis en place sur les membres du CAS array et issu de votre PKI d’entreprise.
L’authentification des clients auprès du TMG est de type “HTML Form Authentication”, les credentials de l’utilisateur sont validés via LDAP over SSL auprès d’un RODC sous Windows 2008R2 Core membre du domaine internal.ldap389.info. Plusieurs RODC peuvent être configurés via le LDAP Server Set. La mise en cache des mots de passe pour les utilisateurs accédant à la messagerie est conseillée, dans ce cas utiliser un RODC par site AD. La configuration de l’authentification se fait au niveau du listener OWA sur le TMG:
Pour que TMG puisse communiquer en SSL auprès du RODC le nom rodc.internal.ldap389.info doit être résolu via un fichier host. De même pour une communication sécurisée entre TMG et le CAS array, le nom mail.ldap389.info doit pointer vers le HLB répartissant le trafic externe sur le CAS array (voir host file sur le schéma).
Afin de bénéficier de toutes les fonctionnalités d’une array TMG entreprise, dont la réplication EMS, celle-ci doit être membre d’un domaine (dmz.local). Pour déployer un domaine en DMZ nous vous conseillons la lecture de document. Dans notre cas, le domaine en DMZ n’a pas de relation d’approbation avec le domaine interne, ni aucune redirection DNS (d’où l’emploi de fichiers host dans le paragraphe ci-dessus). Seules les communications sécurisées sont autorisées de la “DMZ privée” vers le réseau interne.
Afin de sécuriser ce domaine en DMZ (trafic en bleu sur le schéma), les contrôleurs de domaine sont placés dans un subnet dédié de la “DMZ privée”, qui n’accepte aucun trafic venant de l’internet. Les TMG s’authentifient uniquement auprès de RODC 2008R2 core, le port DNS TCP 53 doit tout de même être ouvert vers le PDCe, seul RWDC du domaine, afin de permettre la mise à jour DNS des clients (voir How does the client DNS update referral mechanism work?). Pour joindre vos serveurs TMG auprès d’un RODC utiliser ce script. Si vous désirez sécuriser encore plus ce domaine vous pouvez aussi mettre en place un administrateur local pour les RODC et interdire la mise en cache des mots de passe des administrateurs du domaine. Vous pouvez aussi paramétrer la valeur CachedLogonCounts sur vos TMG à 0, mais vous ne pourrez pas vous loguer sur la machine avec un compte du domaine dmz.local si aucun contrôleur de domaine n’est disponible.
Dans cette configuration votre TMG est membre d’un domaine en DMZ sécurisé et vous permet de bénéficier de toutes les fonctionnalités du produit dans sa version Enterprise.
This post is also available in: Anglais
